08:41:41 <tsoome> great. panic in fifo_read() because fnp->fn_mp is NULL, which should not happen according to this ASSERT...
14:47:20 <denk> guys, could you test bhyve?
14:47:22 <denk> 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
14:47:25 <denk> Assertion failed: err == 0, file rtc.c, line 125, function rtc_init
14:48:03 <denk> without -u ioctl() returns EINVAL in the function
14:48:23 <denk> 561:    ioctl(3, (('v'<<16)|('m'<<8)|16), 0xFFFFFC7FFFDF2560) Err#22 EINVAL
14:48:23 <denk> Assertion failed: err == 0, file rtc.c, line 125, function rtc_init
14:48:23 <denk> 561:    write(2, " A s s e r t i o n   f a".., 68)      = 68
14:52:50 <andyf> What's your system clock set to?
14:53:41 <denk> my local timezone
14:53:56 <denk> lenovo# date
14:53:56 <denk> Tue Feb 20 17:53:48 MSK 2024
14:54:47 <jbk> hrm.. truss -v i don't think will show the timespec_t being passed
14:55:01 <andyf> 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 ...'
14:55:02 <denk> https://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/bhyve/rtc.c?r=32640292#123
14:55:26 <jbk> but it looks like that fails w/ EINVAL if tv_sec < 0 or tv_nsec > NANOSEC
14:55:32 <andyf> The only EINVAL return seems to be for .. yeah, what jbk said :)
14:55:42 <denk> jbk: +1
14:56:19 <jbk> oh
14:56:21 <jbk> hrm
14:56:30 <jbk> i think we might have an uninitialized variable there
14:56:52 <jbk> err no
14:57:26 <denk> https://paste.dilos.org/?df7a3bd27a0b7e6e#7ZZi+N85JJPP30nPulYrttEkr+EC2RwpvQtN6Asvykk=
14:57:34 <denk> dtrace result
14:57:47 <andyf> So the `tv_sec` value is the problem
14:57:58 <jbk> yeah
14:58:14 <jbk> unfortunately i've got my daily morning team meeting in 2 mins
14:58:40 <jbk> 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
14:59:12 <jbk> the one thing would be to know if rtc.use_localtime is set or not
14:59:17 <jbk> as that could alter the value of ts
14:59:26 <jbk> (to track down where the -1 is coming from)
14:59:54 <denk> file a bug for the future
14:59:58 <andyf> denk - run the bhyve command with an added `-o config.dump=1`
15:00:12 <andyf> that will dump out the final configuration, and then look for and `rtc` keys there
15:01:06 <denk> andyf: https://paste.dilos.org/?237534e6708cde4b#skRQCJyDcio207ixpB4PFkICtk3ei6+LJ0Z6paZpz+w=
15:01:57 <andyf> 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
15:03:37 <andyf> It's a bit longer but hopefully I got this right
15:03:38 <andyf> dtrace -n 'pid$target::clock_gettime:e
15:03:38 <andyf> ntry{self->ts = args[1]}' -n 'pid$target::clock_gettime:return{print(*self->ts)}
15:03:38 <andyf> ' -c 'bhyve -HPD ...'
15:04:01 <andyf> dtrace -n 'pid$target::clock_gettime:entry{self->ts = args[1]}' -n 'pid$target::clock_gettime:return{print(*self->ts)}' -c 'bhyve -HPD ...'
15:05:06 <denk> andyf: I guess the bug confirmed, isn't it?
15:07:16 <andyf> 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.
15:07:43 <andyf> bhyve could show a better error message, but it doesn't seem to be at fault here
15:08:10 <andyf> There are tests for clock_gettime() so it would definitely be worth running them on that system
15:08:42 <andyf>  /opt/os-tests/tests/clock_gettime.64 for example, if you have system/test/ostest installed
15:09:33 <denk> I did not install any test on that laptop, sorry
15:10:44 <andyf> Does that last dtrace line show anything?
15:10:59 <andyf> This one https://log.omnios.org/illumos/2024-02-20#1708441441-743120
15:12:49 <denk> https://paste.dilos.org/?4e8fde19e22198ed#eQeApxkOMfcAn4RZC4gojulnpI3XDbCzZFjqXn+h9LQ= where am I wrong?
15:13:11 <andyf> Missed the `-c` before the command
15:14:07 <denk> https://paste.dilos.org/?25667c3e37cc69fb#mPMQXg+6Amcou9Cef5/07x4SbZTSxD3cRbZLpF2X3aE=
15:20:45 <andyf> 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])}' 
15:23:11 <denk> let's try to it
15:23:47 <denk> https://paste.dilos.org/?d395506a17a3f3e6#OyMIxj6O/LhiZo9gUh2QxP0nPkrGsZPyzmigQVuBM2Q=
15:25:20 <andyf> Well, I can't explain that based on the code I'm looking at in illumos-gate - https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/bhyve/rtc.c#L122-L123
15:25:43 <andyf> 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()
15:26:06 <andyf> At this point I think I would start disassembling that function and using instruction tracing to work out what is happening
15:26:20 <andyf> I can't replicate it on omnios or helios. Are you using openindiana?
15:26:43 <denk> nope, dilos
15:27:01 <denk> thanks anyway for your time
15:27:10 <andyf> I think you need to look for differences around there, or in libvmmapi then. Good luck
17:14:00 <gitomat> [illumos-gate] 16294 Appease pkglint regarding secondary python version -- Andy Fiddaman <illumos⊙fn>
21:22:09 <hirigaray> so... how many of you are running helios to poke around? 
21:22:33 <hirigaray> hello by the way lol
22:46:32 <antranigv> hirigaray hello
22:46:47 <antranigv> hirigaray not helios, but I'm running OmniOS and SmartOS :)
22:47:01 <antranigv> I should try running helios
22:50:53 <hirigaray> i did install helios on my spare x220 and it's running
22:51:07 <hirigaray> but it's also my first illumos distro... so, probably not the right place to start
22:51:57 <antranigv> I should try booting it in bhyve
22:52:07 <antranigv> hirigaray how did you install it?
22:53:14 <hirigaray> antranigv: https://github.com/oxidecomputer/helios-engvm 
22:53:28 <hirigaray> theres instructions there, but basically, i just downloaded the vga iso, booted it up and installed it
22:53:34 <hirigaray> no issues at all, i was very happy
22:54:16 <antranigv> hirigaray nice!
22:55:11 <hirigaray> but now I am not sure what exactly I can/should do with it :D I am basically exploring illumos
22:55:16 <hirigaray> learning all the illumos basics