Strange panic at boot with vmm in loader.conf vs manually loading it

[Allan Jude]

On 10/12/2018 11:52, Mike Tancsa wrote:
> I am guessing this does not have anything to do with vmm being loaded,
> but hardware being initialized in a particular order? If I load vmm in
> loader.conf, the box panics at boot up.  However, manually loading it
> all seems to work.  Hardware is PRIME X370-PRO, AMD Ryzen 5 1600X 32G
> RAM.  FreeBSD 12.0-ALPHA9 r339328 GENERIC-NODEBUG
> 
> 
> Leading up to the crash, I see
> 
> 
> ugen0.1: <0x1022 XHCI root HUB> at usbus0
> ugen1.1: <0x1b21 XHCI root HUB> at usbus1
> Trying to mount root from zfs:zroot/ROOT/default []...
> uhub0: ugen2.1: <0x1022 XHCI root HUB> at usbus2
> Root mount waiting for: usbus2<0x1022 XHCI root HUB, class 9/0, rev
> 3.00/1.00, addr 1> on usbus0
>   usbus1 usbus0
> uhub1: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2
> uhub2: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1
> uhub2: 4 ports with 4 removable, self powered
> uhub1: 8 ports with 8 removable, self powered
> uhub0: 22 ports with 22 removable, self powered
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x398
> fault code              = supervisor write data, page not present
> instruction pointer     = 0x20:0xffffffff8273d776
> stack pointer           = 0x28:0xfffffe0075d55230
> frame pointer           = 0x28:0xfffffe0075d55270
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                          = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 1 (kernel)
> [ thread pid 1 tid 100002 ]
> Stopped at      rrw_enter_read_impl+0x36:       lock cmpxchgq
> %r14,0x18(%rbx)
> db> bt
> Tracing pid 1 tid 100002 td 0xfffff8000567d580
> rrw_enter_read_impl() at rrw_enter_read_impl+0x36/frame 0xfffffe0075d55270
> zfs_mount() at zfs_mount+0x7b2/frame 0xfffffe0075d55400
> vfs_domount() at vfs_domount+0x5b2/frame 0xfffffe0075d55630
> vfs_donmount() at vfs_donmount+0x930/frame 0xfffffe0075d556d0
> kernel_mount() at kernel_mount+0x3d/frame 0xfffffe0075d55720
> parse_mount() at parse_mount+0x451/frame 0xfffffe0075d55860
> vfs_mountroot() at vfs_mountroot+0x7a0/frame 0xfffffe0075d559f0
> start_init() at start_init+0x27/frame 0xfffffe0075d55a70
> fork_exit() at fork_exit+0x83/frame 0xfffffe0075d55ab0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0075d55ab0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> db>

Strange that your crash is in ZFS here...

Can you take a crash dump?

It looks like something is trying to write to uninitialized memory here.

> 
> On a normal boot, the next line would be atrtc0
> 
> uhub0: Root mount waiting for: usbus2ugen2.1: <0x1022 XHCI root HUB> at usbus2
> <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
>   usbus1 usbus0uhub1: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1
> 
> uhub2: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2
> uhub1: 4 ports with 4 removable, self powered
> uhub2: 8 ports with 8 removable, self powered
> uhub0: 22 ports with 22 removable, self powered
> atrtc0: providing initial system time
> start_init: trying /sbin/init
> Setting hostuuid: c3297ba0-3f01-11e7-8725-6045cba08a84.
> Setting hostid: 0x094fa67e.
> Starting file system checks:
> Mounting local filesystems:.

snip

> 
> 
> 	---Mike
> 
> 
> 


-- 
Allan Jude