virtualbox 5.2.20 triggers panic with FreeBSD 12.0-ALPHA10 r339432

It looks like there are a couple of problems here.  The first is that
when I attempt to start a Virtualbox VM, the system panics.  The DDB
backtrace seems to indicate that the panic is occuring inside the
ng_ether module, which was being called due to a virtualbox doing an
ioctl call.  The VM guest is M$ Windows 7 with networking configured as
NAT and the underlying adapter being Intel PRO/1000 MT Desktop
(82540EM).

I got a crash dump, but the second problem is that the stack backtrace
doesn't unwind the stack leading to the panic, but rather just the ddb
stack to the doadump call.  The panic is likely to be easily
reproduceable, so I can take a screen photo of the DDB output and upload
it if necessary.

Fri Oct 19 15:27:58 PDT 2018

FreeBSD zipper.catspoiler.org 12.0-ALPHA10 FreeBSD 12.0-ALPHA10 r339432 GENERIC
 amd64

panic:

GNU gdb (GDB) 8.2 [GDB v8.2 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/lib/debug//
boot/kernel/kernel.debug...done.
done.

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 6; apic id = 06
fault virtual address   = 0x80a40ac00
fault code              = supervisor read data, protection violation
instruction pointer     = 0x20:0xffffffff82ece023
stack pointer           = 0x28:0xfffffe02978ef3c0
frame pointer           = 0x28:0xfffffe02978ef3d0
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         = 92279 (VirtualBox)

__curthread () at ./machine/pcpu.h:230
230             __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) #0  __curthread () at ./machine/pcpu.h:230
#1  doadump (textdump=-2118704256) at /usr/src/sys/kern/kern_shutdown.c:366
#2  0xffffffff8043df6c in db_fncall_generic (addr=<optimized out>,
    rv=<optimized out>, nargs=<optimized out>, args=<optimized out>)
    at /usr/src/sys/ddb/db_command.c:609
#3  db_fncall (dummy1=<optimized out>, dummy2=<optimized out>,
    dummy3=<optimized out>, dummy4=<optimized out>)
    at /usr/src/sys/ddb/db_command.c:657
#4  0xffffffff8043daa9 in db_command (last_cmdp=<optimized out>,
    cmd_table=<optimized out>, dopager=<optimized out>)
    at /usr/src/sys/ddb/db_command.c:481
#5  0xffffffff8043d824 in db_command_loop ()
    at /usr/src/sys/ddb/db_command.c:534
#6  0xffffffff80440a3f in db_trap (type=<optimized out>, code=<optimized out>)
    at /usr/src/sys/ddb/db_main.c:252
#7  0xffffffff80bd52a3 in kdb_trap (type=12, code=0, tf=<optimized out>)
    at /usr/src/sys/kern/subr_kdb.c:693
#8  0xffffffff81062fc1 in trap_fatal (frame=0xfffffe02978ef300,
    eva=34531748864) at /usr/src/sys/amd64/amd64/trap.c:921
#9  0xffffffff810630e2 in trap_pfault (frame=0xfffffe02978ef300,
    usermode=<optimized out>) at /usr/src/sys/amd64/amd64/trap.c:765
#10 0xffffffff8106270a in trap (frame=0xfffffe02978ef300)
    at /usr/src/sys/amd64/amd64/trap.c:441
#11 <signal handler called>
#12 0xffffffff82ece023 in ?? ()
#13 0x0000000000000000 in ?? ()