15:11:24 <spicywolf> Any tips for running omnios on linux kvm?  Looks like it starts loading the kernel then hard resets.
15:12:19 <spicywolf> This is both off the installer iso and the qcow2 image.
15:13:14 <andyf> Can you turn on the kernel debugger (kmdb) from the loader menu and see if reports more information when it resets?
15:13:38 <spicywolf> Yeah lemme see what it says.
15:13:45 <andyf> I can't remember the exact path but it's something like Boot Options -> KMDB
15:15:41 <spicywolf> Yeah, it was 5 (boot options) -> 7 (kmdb mode).
15:16:49 <spicywolf> Looks like its throwing "Bad kernel fault at addr=0xfffffe0b8b006370" I'm not totally sure what I'm doing here though.
15:18:15 <spicywolf> Looking through the stack trace on screen, it went main+36 -> startup+5a -> real_mode_stop_cpu_stage2_end+7221
15:18:30 <spicywolf> And then into a bcopy, which threw a trap.
15:19:07 <andyf> Can you paste the output of the `::status` and `$C` commands somewhere? (https://paste.omnios.org is one option)
15:19:07 <tsoome> or use boot -k ;) 
15:19:19 <andyf> We'd definitely expect this to work so would like to fix whatever's going on.
15:22:24 <spicywolf> Yeah, lemme transcribe it from the framebuffer real quick.  ::status only returns a few lines, the last of which is "stopped on: debugger entry trap".
15:28:29 <spicywolf> Okay, um.  What boot options do I need to get kmdb over on the serial port?
15:29:01 <spicywolf> "text" option is vga.  yep.
15:29:34 <andyf> Boot options, Os Console = ttya should work
15:32:27 <spicywolf> https://paste.sr.ht/~spicywolf/b35eb450117b7c4fd61b701cfe73a87c6cc909fa
15:33:09 <spicywolf> Looks like it was caused by a page fault?
15:38:25 <spicywolf> I'm gonna read up on kmdb rq, see what other info I can get outta this.  It may entirely be an issue with the virtual hardware setup, but if so, I don't know what exactly.
15:42:12 <andyf> Can you do `$C -v` to get the function arguments?
15:42:38 <spicywolf> It produces the same output.
15:49:11 <andyf> Ah right, that makes sense as `$C` is already verbose (unlike `$c`)
15:55:48 <spicywolf> Would you like my virtual machine manifest?  See if I have anything configured incorrectly compared to what's expected?  I'm having a hard time finding examples of known good configurations.
15:56:36 <andyf> So it's a page fault in "repz movsq (%rsi),(%rdi)" where rsi is fffffe0b8b006370 and rdi is fffffe0bd2bf4000, and rsi was the responsible address.
15:56:47 <andyf> I got the instruction from `bcopy_ck_size+0xea::dis`
16:00:25 <spicywolf> I see.  Is there something I can do about this?  Or...?  I'm not sure what rsi is supposed to represent here?
16:00:54 <andyf> You're somewhere in `startup_end()` but I don't know exactly where.
16:01:07 <andyf> Try `fffffe0b8b006370::whatis`
16:01:36 <andyf> I don't know much about KVM but it's worth sharing the manifest in case somebody here has an idea, or can replicate and dig into it.
16:02:11 <andyf> I've booted omnios under KVM on omnios before, and under qemu, but not on Linux.
16:02:16 <andyf> and the omnios KVM is old now
16:02:58 <spicywolf> Alright, give me a second, and I'll get a new paste thrown together.
16:08:54 <andyf> I have to step away. Back around later.
16:10:59 <spicywolf> No worries.  I also have to for a bit.
16:11:41 <spicywolf> https://paste.sr.ht/~spicywolf/9de59e7b8f15a6aac8ac778682e5606438699c04 this is the kvm manifest, as well as the combined outputs from before and the ::whatis on that address.
16:52:15 <spicywolf> So the disassembly of address fffffffffb864ffa produces "testq %rax,%rax", but that... can't possibly be right.  It is immediately preceeded by a call to smbios_open, but wouldn't the stack trace actually show that?  Whatever's going on, it looks like it is trying to iterate over devices.  That address 0xfffffe0b8b006370::whatis shows that its an allocation from the device vmem arena.  I don't know, I definitely don't understand the boot proc
16:52:15 <spicywolf> ess well enough for this, and I'm probably going to have to brush up really well with mdb to competently help debug this.
16:53:20 <spicywolf> I'm going to kill the vm for now.
17:55:09 <m1ari> spicywolf: scanning through your manifest the i440fx chipset seems to be quite old (wikipedia says it dates back to P3 times), Trying to create a new VM I get the options for i440fx and Q35 chipsets, I wonder if using Q35 might work better
17:56:15 <m1ari> I was trying to compare the XML with a Linux VM I've got on a Fedora host here (I don't think I've tried OmniOS in a VM for a long time)
17:57:59 <m1ari> the other quick difference I've seen is my CD-ROM device shows <target dev="sda" bus="sata"/> compared to yours using hda and ide
18:43:34 <spicywolf> I wasn't aware of what CPU options were available.  I'll give these changes a try.  honestly I think a lot of options are hidden behind that libosinfo.
18:48:03 <m1ari> I think you get a bunch of defaults based on what OS it selects at the start - I'm not sure how that's defined.
18:52:22 <m1ari> I don't know if that's the actual problem, just a couple of obvious differences I could see quickly
18:54:52 <nomad> ugh. kernel panic in smbsrv due to a null pointer dereference.
18:55:00 <nomad> I'm supposed to be on vacation!
18:59:38 <nomad> I'm doing a savecore -f /dev/zvol/dsk/rpool/dump and it isn't giving any errors so I presume it survived the host coming back up multiuser.