14:17:53 ISTR (though can't recall exactly where) someone mentioned that oxide found disabling I think it was the sorting of I/Os by LBA in the vdev scheduler improved performance w/ all NVMe pools -- is there a commit somewhere with the change? I'm curious to mess with it for some things 14:18:38 (I don't see any vdev_queue.c changes in their stlouis branch, which seems like it's their main branch?) 15:11:53 tsoome: sorry to ping you directly. did you have any chance to look at smbios issue (as in "table not being exported") I raised some time ago? 16:19:22 tsoome: newer (i'd need to dig a bit to track back versions) loader seem to hang accessing the HD on hyper-v (haven't tried azure yet) 16:19:39 when booted off the omnios ISO, and you select boot from HD, I see LoadImage failed 16:19:59 but when booting directly from disk, it just hangs after loading /boot/defaults/loader.conf 16:50:48 [illumos-gate] 17346 Want tools for testing tz changes -- Robert Mustacchi 16:50:48 [illumos-gate] 17344 Update tools to tzcode 2025a -- Robert Mustacchi 16:50:49 [illumos-gate] 17345 Update to tzdata 2025b -- Robert Mustacchi 17:11:03 oh hrm.. i think i see what happened... 19:09:33 [illumos-gate] 17395 race in hotplug leads to ndi_devi_enter deadlock -- Dan Cross 20:04:15 jbk hm? 20:04:59 omnios decides to remove text from the loader console if you activate the serial port during install apparently and doesn't start a ttymon session on the fb console) 20:05:12 so it looks like it hangs 20:05:35 but then it's 'boot from hard drive' option seems to fail with the load image failure as well 20:05:41 when I tried that as an alternative 20:07:11 interesting, why it fails on load image... 20:07:38 that i don't know.. 20:09:29 gemelen I haven't looked more into it --- from loader env we can see the smbios is there (one version or another) because you do have smbios data exposed there. So the big question is, why your userland can not access it. 20:11:19 jbk ya well, we have the same problem grub was poking:) we just check if the result is EFI_SUCCESS and if not, we only do tell it did fail... 20:11:47 it can return handful of error codes there:) 20:13:48 tsoome: yep. do you have any directions, so I'd be able to investigate on my own? 20:15:59 we do pass smbios-address property to kernel, you can check the presence and value from prtconf -v output 20:16:59 something like: name='smbios-address' type=int64 items=1 value=000000007ba78000 20:39:58 yep, it's present, but differs from what I saw as the address reported by linux, for example. I'll start from here, thanks 20:41:41 what is the value there btw? 20:44:07 name='smbios-address' type=int64 items=1 value=00000000dbabab98 20:50:43 anything from grep SMBIOS /var/adm/messages* ? 20:52:18 if I remember the most it logs is that there isn't one, in cases like that 20:53:08 gemelen: What was the original error message that you had? 20:56:12 rmustacc: when running a smbios or prdiag, I get "failed to open SMBIOS: System does not export an SMBIOS table" 20:57:48 tsoome:" genunix: [ID 285365 kern.notice] smbios: cannot read .dynamic section" and "unix: [ID 672469 kern.info] SMBIOS not loaded (System does not export an SMBIOS table)" 20:58:47 If I give you a few lines of DTrace just to confirm, would you be able to run that? 21:01:22 sure 21:02:14 oh, "cannot read .dynamic section" is new on the case where it purely doesn't find anything 21:03:16 dtrace -n 'fbt::smbios_open:entry{ self->t = args[3]; }' -n 'fbt::smbios_open:return/self->t/{ print(*args[1]); print(*self->t); self->t = NULL }' -c 'smbios -e' 21:03:58 The thing that's a bit weird is that this suggests that when we scan the page that the loader gave us an address for we didn't find a SMBIOS 2.x or 3.x anchor string. 21:04:35 rmustacc: https://gist.github.com/gemelen/888f5a280632f326e0ddf10e763ca0fb?permalink_comment_id=5556476#gistcomment-5556476 21:05:06 Hmm. I guess it's using something cached then. 21:19:42 well. you can do simple experiment; boot to loader prompt (press esc to get out of menu to ok prompt), enter there: 0xdbabab98 20 dump 21:28:52 if that's physical, you should be able to look with mdb too 21:30:09 identity mapped, so yes, its physical 21:42:14 tsoome: https://gist.github.com/gemelen/888f5a280632f326e0ddf10e763ca0fb?permalink_comment_id=5556517#gistcomment-5556517 21:42:49 (if I'd have a serial cable it'd be a bit faster) 21:45:30 _SM_ is there, um length 20 was not the best, 32 would be better, I guess. 21:47:17 ummhttps://github.com/illumos/illumos-gate/blob/master/usr/src/uts/i86pc/os/smb_dev.c#L103 21:47:20 should that be || ? 21:47:48 i haven't looked at the spec in a while 21:48:37 Just on the surface that seems ok to me. 21:49:10 break out if you've found something for both smb2 and smb3, else keep looking until the end of the list 21:49:11 jbk: it's scanning until it runs out of buffer or finds both smb2 and smb3 21:49:40 That's fine. That's what you want because you want to prefer the smb3 entry point over smb2 for example. 22:19:11 ^ https://gist.github.com/gemelen/888f5a280632f326e0ddf10e763ca0fb?permalink_comment_id=5556542#gistcomment-5556542