I finally decided to upgrade dax from FreeBSD 8.3-RELEASE to 9.1-RELEASE while stepping through 9.0-RELEASE.  As alawys, I hit a snag.

When stepping through 9.0-RELEASE to get to 9.1-RELEASE (I'm not sure if this is really required but I figured it wouldn't hurt) I ran into a nasty situation with the VirtualBox kernel modules.  Specifically, the kernel module vboxnetflt.ko in the 4.2.16 version of VirtualBox causes the FreeBSD kernel to panic before it's even mounted the root file system:

[.. output trimmed ..]
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
coretemp0: <CPU On-Die Thermal Sensors> on cpu0
coretemp1: <CPU On-Die Thermal Sensors> on cpu1
coretemp2: <CPU On-Die Thermal Sensors> on cpu2
coretemp3: <CPU On-Die Thermal Sensors> on cpu3
Timecounters tick every 1.000 msec


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address    = 0xc
fault code          = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80cb2717
stack pointer          = 0x28:0xffffffff80d17ab0
frame pointer          = 0x28:0xffffffff80d17ad0
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          = 0 (swapper)
trap number         = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0xffffffff804d752e at kdb_backtrace+0x5e
#1 0xffffffff804a20e7 at panic+0x187
#2 0xffffffff806e9140 at trap_fatal+0x290
#3 0xffffffff806e9489 at trap_pfault+0x1f9
#4 0xffffffff806e994f at trap+0x3df
#5 0xffffffff806d3def at calltrap+0x8
#6 0xffffffff80c94c52 at supdrvCleanupSession+0x52
#7 0xffffffff80c94ee1 at supdrvCloseSession+0x11
#8 0xffffffff80c9622b at supdrvIDC+0x10b
#9 0xffffffff80cf3ee6 at supR0IdcNativeCall+0x16
#10 0xffffffff80cf40a0 at SUPR0IdcClose+0xa0
#11 0xffffffff80cf3809 at vboxNetFltInitIdc+0x79
#12 0xffffffff80cf3857 at vboxNetFltInitGlobalsAndIdc+0x27
#13 0xffffffff80cf312b at vboxnetflt_modevent+0x3b
#14 0xffffffff80cfb634 at ng_mod_event+0x44
#15 0xffffffff804912c8 at module_register_init+0xb8
#16 0xffffffff80456ac7 at mi_startup+0x77
#17 0xffffffff8027177c at btext+0x2c
Uptime: 2s
Automatic reboot in 15 seconds - press a key on the console to abort
--> Press a key on the console to reboot,
--> or switch off the system now.
Rebooting...

As a result, dax was stuck in an endless reboot for 15-20 minutes as I drove home, since I did the upgrade while mobile.  It also took me awhile to figure out how to not load the vboxnetflt.ko at boot since I only had access to the loader prompt.  The disable-module directive didn't seem to work:

OK lsmod
 0x200000: /boot/kernel/kernel (elf kernel, 0xa46fb0)
  modules: x86bios.1 io.1 ufs.1 kernel_mac_support.4 [.. trimmed ..] 
 0xc47000: /boot/kernel/linux.ko (elf obj module, 0x45078)
  modules: linux.1 
 0xc8d000: /boot/kernel/accf_http.ko (elf obj module, 0x17d0)
 0xc8f000: /boot/kernel/coretemp.ko (elf obj module, 0x29e0)
 0xc92000: /boot/modules/vboxdrv.ko (elf obj module, 0x59c40)
  modules: vboxdrv.1 
 0xcec000: /boot/modules/vboxnetadp.ko (elf obj module, 0x5bf0)
  modules: vboxnetadp.1 
 0xcf2000: /boot/modules/vboxnetflt.ko (elf obj module, 0x7568)
  modules: vboxnetflt.1 
 0xcfa000: /boot/kernel/netgraph.ko (elf obj module, 0x15440)
  modules: netgraph.12 
OK disable-module vboxnetflt
vboxnetflt was not found
OK disable-module /boot/modules/vboxnetflt.ko
/boot/modules/vboxnetflt.ko was not found
OK disable-module vboxnetflt.1
vboxnetflt.1 was not found

It would always load vboxnetflt.ko, for some reason.  Apparently the trick was to unload all modules, load the kernel manually, and then boot.  These steps got the system up and running again.  The first thing I did was rename vboxnetflt.ko, of course.

I'm hoping this problem is fixed in 9.1-RELEASE, which I don't have time to mess with now but I'll probably get to tomorrow evening.  I wasn't able to find much via web searching related to this type of problem, unfortunately.  I can't be the only one encountering this, can I?

Update: It looks like taking the vbox* modules out of loader.conf and loading them after the OS is started fixes the problem.  For some reason vboxnetflt.ko freaks out when loaded at boot.  Instructions here are good to follow, too.

New comments are currently disabled for this entry.