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

In message <8f033c7c-af8f-1ebc-d787-548634f104e3_at_freebsd.org>, Allan 
Jude write
s:
> 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 pres
> ent
> > 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, de
> f32 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.
>

I was digging into this before I left on vacation. You can recreate 
this by,

mount -t zfs tank/nonexistent /mnt

A nonexistent dataset or zpool triggers the panic. I discovered it by 
chance through a typo in fstab. The panic occurs with INVARIANTS. 
Without INVARIANTS results in a hard hang.

I got as far as discovering that f_mntfromname pointed to a null string 
but ran out of time before I left.


-- 
Cheers,
Cy Schubert <Cy.Schubert_at_cschubert.com>
FreeBSD UNIX:  <cy_at_FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.