great. panic in fifo_read() because fnp->fn_mp is NULL, which should not happen according to this ASSERT...

guys, could you test bhyve?

lenovo# bhyve -HPD -s 0:0,hostbridge,model=amd -s 31,lpc -l bootrom,/usr/share/bhyve/uefi-rom.bin -c 4 -m 4g test

Assertion failed: err == 0, file rtc.c, line 125, function rtc_init

without -u ioctl() returns EINVAL in the function

561: ioctl(3, (('v'<<16)|('m'<<8)|16), 0xFFFFFC7FFFDF2560) Err#22 EINVAL

Assertion failed: err == 0, file rtc.c, line 125, function rtc_init

561: write(2, " A s s e r t i o n f a".., 68) = 68

What's your system clock set to?

my local timezone

lenovo# date

Tue Feb 20 17:53:48 MSK 2024

hrm.. truss -v i don't think will show the timespec_t being passed

Can you try wrapping that command in dtrace to see what is actually being passed through to the kernel? Something like: dtrace -n 'vrtc_set_time:entry{print(*args[1])}' -c 'bhyve -HPD ...'

but it looks like that fails w/ EINVAL if tv_sec < 0 or tv_nsec > NANOSEC

The only EINVAL return seems to be for .. yeah, what jbk said :)

jbk: +1

oh

hrm

i think we might have an uninitialized variable there

err no

dtrace result

So the `tv_sec` value is the problem

yeah

unfortunately i've got my daily morning team meeting in 2 mins

and we just had a long weekend, so it's almost certainly going to run long.. so i'll have to step aside for the moment

the one thing would be to know if rtc.use_localtime is set or not

as that could alter the value of ts

(to track down where the -1 is coming from)

file a bug for the future

denk - run the bhyve command with an added `-o config.dump=1`

that will dump out the final configuration, and then look for and `rtc` keys there

andyf: paste.dilos.org/?237534e6708cde4b#s…io207ixpB4PFkICtk3ei6+LJ0Z6paZpz+w=

Not set, so what appears to be happening is that `clock_gettime(CLOCK_REALTIME, ts)` is returning an invalid value. We can check that with dtrace too

It's a bit longer but hopefully I got this right

dtrace -n 'pid$target::clock_gettime:e

ntry{self->ts = args[1]}' -n 'pid$target::clock_gettime:return{print(*self->ts)}

' -c 'bhyve -HPD ...'

dtrace -n 'pid$target::clock_gettime:entry{self->ts = args[1]}' -n 'pid$target::clock_gettime:return{print(*self->ts)}' -c 'bhyve -HPD ...'

andyf: I guess the bug confirmed, isn't it?

If that latest dtrace shows that the system call is returning -1 in the seconds field, that implies a kernel bug somewhere but it will need more investigation to find the cause.

bhyve could show a better error message, but it doesn't seem to be at fault here

There are tests for clock_gettime() so it would definitely be worth running them on that system

/opt/os-tests/tests/clock_gettime.64 for example, if you have system/test/ostest installed

I did not install any test on that laptop, sorry

Does that last dtrace line show anything?

This one log.omnios.org/illumos/2024-02-20#1708441441-743120

paste.dilos.org/?4e8fde19e22198ed#e…fcAn4RZC4gojulnpI3XDbCzZFjqXn+h9LQ= where am I wrong?

Missed the `-c` before the command

Well that looks ok. Can you use both dtrace lines together? Add this to the one you just ran: -n 'vrtc_set_time:entry{print(*args[1])}'

let's try to it

Well, I can't explain that based on the code I'm looking at in illumos-gate - github.com/illumos/illumos-gate/blo…r/usr/src/cmd/bhyve/rtc.c#L122-L123

The timestamp is right when it comes back from the kernel, but the seconds element gets replaced with -1 before the call to vm_rtc_settime()

At this point I think I would start disassembling that function and using instruction tracing to work out what is happening

I can't replicate it on omnios or helios. Are you using openindiana?

nope, dilos

thanks anyway for your time

I think you need to look for differences around there, or in libvmmapi then. Good luck

[illumos-gate] 16294 Appease pkglint regarding secondary python version -- Andy Fiddaman <illumos⊙fn>

so... how many of you are running helios to poke around?

hello by the way lol

hirigaray hello

hirigaray not helios, but I'm running OmniOS and SmartOS :)

I should try running helios

i did install helios on my spare x220 and it's running

but it's also my first illumos distro... so, probably not the right place to start

I should try booting it in bhyve

hirigaray how did you install it?

antranigv: github.com/oxidecomputer/helios-engvm

theres instructions there, but basically, i just downloaded the vga iso, booted it up and installed it

no issues at all, i was very happy

hirigaray nice!

but now I am not sure what exactly I can/should do with it :D I am basically exploring illumos

learning all the illumos basics