VirtualBox 4.1.14 panic

[Bernhard Fröhlich]

On Tue, May 8, 2012 at 4:25 AM, Sean C. Farley <scf at freebsd.org> 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

This looks similar to the problem described in ports/169565. Could you please
try the described modification there and see if it helps?

http://www.freebsd.org/cgi/query-pr.cgi?pr=169565

-- 
Bernhard Froehlich
http://www.bluelife.at/