04:19:09 @jbk --> if I sent you a vmware.log file, could you *quickly and easily* see if there's SATA weirdness? 04:20:14 i don't konw :) 04:20:30 i can at least give it a shot 04:21:01 Mailing... 04:21:34 And by "SATA weirdness" I mean "VMware SATA weirdness that'd make the illumos guest have horrid ZFS errors not explainable by code-changes). 04:25:10 we tend to use pvscsi for people using our stuff in vmware, so not sure we've done much with the sata driver in there... 04:25:24 but given vmware's scsi behavior, it wouldn't surprise me if there's strangeness 04:25:36 You know SATA better. Pardon delay, talking about BaseT stuff elsewhere. 04:39:40 nothing's standing out yet aside from something not getting that a CDROM isn't going to support SCSI reservations or SYNC cache requests, yet it persists 04:41:53 CDROM is physically detached. if that's all it is then I"m not sure. 04:42:05 I'm re-running the tests on a DIFFERENT VMware Fusion client. 04:42:20 (This is the gcc14 build of this week's SmartOS.) 04:42:34 AI seems to suggests that 'PxSCTL.DET already 0.' which appears to be for the non-CDROM SATA disks (it looks like there's perhaps several attached?) 04:43:07 means a possible corrupted VM config file... but it's AI, so take it with BP bursting amounts of salt... 04:43:31 (is there a reason to not use pvscsi?) 04:44:10 i'd need to dig a bit to see what that actually means... I _think_ that might be referring to an AHCI register (or a bit in one) 04:44:29 but I don't recall _that_ level of detail for SATA stuff offhand :) 04:49:56 @jbk sloth on my part, Ithink. 18:30:17 We may still have some mdb post-mortem-debugging problems. See fenix illumos#17681 18:30:18 BUG 17681: mdb `::whatis` on kernel dump is SUPER NOISY. (New) 18:30:18 ↳ https://www.illumos.org/issues/17681 19:33:03 [illumos-gate] 17657 Want SMBIOS TPM (Type 43) decoding -- Robert Mustacchi 19:33:03 [illumos-gate] 17656 print Endian-corrected SMBIOS UUID -- John Levon 19:33:03 [illumos-gate] 17655 Add Phoenix 2 amdzen(4D) IDs -- Robert Mustacchi 20:08:36 danmcd: see my msg 20:23:31 on a separate topic... there's this 'ddi_xbuf_t' stuff that only seems to be used by sd.c but seems like it was maybe intended at some point (likely distant past) to be some more general api 20:34:38 what do you wonder specifically? 20:35:18 it seems like it's implementing it's own queue on top of all the other bits 20:36:36 well, I can't find any useful history either. It smells of a hack 'cos I/O was slow though, doesn't it 20:36:37 just curious if anyone's looked at it.. or thought if it's still useful... 20:37:07 yeah, and I'm just getting closer to my pain threshold of dealing with sd.c where I might actually do something :P 23:47:45 i'm probably confusing things, but I vaguely remember a way I think with libumem to force a program to coredump at exit(1) (e.g. I want to force one to run umem) 23:48:04 trying to see if I can force the leak in #17676 (which was just found from looking at the code) 23:49:04 unless advocates are ok with just calling passwd and making sure check_circular() still works before/after or such.. 23:50:25 I don't think there's an existing way, but you can set a breakpoint on exit or the return from main and just grab a core. 23:50:33 (Or run it there) 23:51:01 fmtopo has an explicit core on exit flag which may be what you're thinking of? 23:52:33 could be...