VirtualBox 4.1.14 panic

[Sean C. Farley]

On Mon, 7 May 2012, Sean C. Farley wrote:

> I experienced a panic while starting a new image using Vagrant[1]. Vagrant 
> uses VBoxManage to do its work.  I was away from my system when it happened, 
> so I do not know exactly at what point it occurred.
>
> This is the last bits of logging I had captured from Vagrant. Fortunately, I 
> had that going for my own purposes (non-panic).  I am almost certain there is 
> more past 30% but was not synced to disk.
>
> DEBUG virtualbox: Finding driver for VirtualBox version: 4.1.14
> INFO virtualbox: Using VirtualBox driver: Vagrant::Driver::VirtualBox_4_1
> INFO virtualbox_base: VBoxManage path: VBoxManage
> INFO vm: Loading guest: linux
> INFO warden: Calling action: #<Vagrant::Action::VM::Import:0x000008032892a8>
> INFO interface: info: Importing base box 'centos-6.2-dev'...
> [default] Importing base box 'centos-6.2-dev'...
> INFO subprocess: Starting process: ["VBoxManage", "import", 
> "/home/blah/.vagrant.d/boxes/centos-6.2-dev/box.ovf"]
> DEBUG subprocess: Selecting on IO
> DEBUG subprocess: stderr: Pseudo-terminal will not be allocated because stdin 
> is not a terminal.
>
> DEBUG subprocess: stderr: 0%...
> DEBUG subprocess: stderr: 
> 10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
> Interpreting /home/blah/.vagrant.d/boxes/centos-6.2-dev/box.ovf...
> OK.
> 0%...
> DEBUG subprocess: stderr: 10%...
> INFO interface: info: ^MESC[0K
> [default] ^MESC[0K INFO interface: info: Progress: 10%
> [default] Progress: 10%DEBUG subprocess: stderr: 20%...
> INFO interface: info: ^MESC[0K
> [default] ^MESC[0K INFO interface: info: Progress: 20%
> [default] Progress: 20%DEBUG subprocess: stderr: 30%...
> INFO interface: info: ^MESC[0K
> [default] ^MESC[0K INFO interface: info: Progress: 30%
> [default] Progress: 30%
>
> Now, for the good stuff.  Unfortunately, the panic was not written to disk 
> correctly, however, here is the bit I did find.  This looks similar to the 
> panic Mikolaj reported[2], but mine appears to be on the shutdown of the VM's 
> network.  My host is 8.3-STABLE r235116 amd64 (Q6600) running with 8GB and 
> the nVidia driver v295.40.  When I noticed the system had frozen (no network 
> either), the screensaver had been running. The screensaver does not use 
> OpenGL out of (probably an old) paranoia that the system could panic from 
> VirtualBox and an OpenGL application running at the same time.  No VIMAGE nor 
> VLAN is involved.  The VM is using NAT.
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 02
> fault virtual address   = 0x12
> fault code              = supervisor read data, page not present
> instruction pointer     = 0x20:0xffffffff81e26394
> stack pointer           = 0x28:0xffffff824790e970
> frame pointer           = 0x28:0xffffff824790e9a0
> 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         = 23702 (initial thread)
> trap number             = 12
> panic: page fault
> cpuid = 2
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> kdb_backtrace() at kdb_backtrace+0x37
> panic() at panic+0x187
> trap_fatal() at trap_fatal+0x290
> trap_pfault() at trap_pfault+0x23e
> trap() at trap+0x3ce
> calltrap() at calltrap+0x8
> --- trap 0xc, rip = 0xffffffff81e26394, rsp = 0xffffff824790e970, rbp = 
> 0xffffff824790e9a0 ---
> vboxNetAdpOsDestroy() at vboxNetAdpOsDestroy+0x14
> vboxNetAdpDestroy() at vboxNetAdpDestroy+0x2d
> VBoxNetAdpFreeBSDCtrlioctl() at VBoxNetAdpFreeBSDCtrlioctl+0x60
> devfs_ioctl_f() at devfs_ioctl_f+0x7b
> kern_ioctl() at kern_ioctl+0x102
> ioctl() at ioctl+0xfd
> amd64_syscall() at amd64_syscall+0x1f4
> Xfast_syscall() at Xfast_syscall+0xfc
> --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800c94bfc, rsp = 
> 0x7fffffffc2f8, rbp = 0x7fffffffc320 ---
> Uptime: 8h31m17s
> Dumping 1351 out of 8163 MB:..2%panic: bufwrite: buffer is not busy???
> cpuid = 2
>
> Sean
>  1. http://vagrantup.com/
>  2. http://lists.freebsd.org/pipermail/freebsd-emulation/2012-April/009646.html

I think this is related to this ticket:
https://www.virtualbox.org/ticket/10562

I found this while searching for a reason a VDI file grew to 28TB from 
32GB.

Sean
-- 
scf at FreeBSD.org