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

(I don't see any vdev_queue.c changes in their stlouis branch, which seems like it's their main branch?)

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?

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)

when booted off the omnios ISO, and you select boot from HD, I see LoadImage failed

but when booting directly from disk, it just hangs after loading /boot/defaults/loader.conf

[illumos-gate] 17346 Want tools for testing tz changes -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 17344 Update tools to tzcode 2025a -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 17345 Update to tzdata 2025b -- Robert Mustacchi <rm⊙fo>

oh hrm.. i think i see what happened...

[illumos-gate] 17395 race in hotplug leads to ndi_devi_enter deadlock -- Dan Cross <cross⊙oc>

jbk hm?

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)

so it looks like it hangs

but then it's 'boot from hard drive' option seems to fail with the load image failure as well

when I tried that as an alternative

interesting, why it fails on load image...

that i don't know..

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.

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...

it can return handful of error codes there:)

tsoome: yep. do you have any directions, so I'd be able to investigate on my own?

we do pass smbios-address property to kernel, you can check the presence and value from prtconf -v output

something like: name='smbios-address' type=int64 items=1 value=000000007ba78000

yep, it's present, but differs from what I saw as the address reported by linux, for example. I'll start from here, thanks

what is the value there btw?

name='smbios-address' type=int64 items=1 value=00000000dbabab98

anything from grep SMBIOS /var/adm/messages* ?

if I remember the most it logs is that there isn't one, in cases like that

gemelen: What was the original error message that you had?

rmustacc: when running a smbios or prdiag, I get "failed to open SMBIOS: System does not export an SMBIOS table"

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)"

If I give you a few lines of DTrace just to confirm, would you be able to run that?

sure

oh, "cannot read .dynamic section" is new on the case where it purely doesn't find anything

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'

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.

rmustacc: gist.github.com/gemelen/888f5a28063…ment_id=5556476#gistcomment-5556476

Hmm. I guess it's using something cached then.

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

if that's physical, you should be able to look with mdb too

identity mapped, so yes, its physical

tsoome: gist.github.com/gemelen/888f5a28063…ment_id=5556517#gistcomment-5556517

(if I'd have a serial cable it'd be a bit faster)

_SM_ is there, um length 20 was not the best, 32 would be better, I guess.

ummhttps://github.com/illumos/illumos-gate/blob/master/usr/src/uts/i86pc/os/smb_dev.c#L103

should that be || ?

i haven't looked at the spec in a while

Just on the surface that seems ok to me.

break out if you've found something for both smb2 and smb3, else keep looking until the end of the list

jbk: it's scanning until it runs out of buffer or finds both smb2 and smb3

That's fine. That's what you want because you want to prefer the smb3 entry point over smb2 for example.

^ gist.github.com/gemelen/888f5a28063…ment_id=5556542#gistcomment-5556542