FBSD 9.2 RC crashes running as virtualbox host

[Kevin Oberman]

On Fri, Aug 16, 2013 at 2:01 PM, Warren Block <wblock at wonkity.com> wrote:

> On Fri, 16 Aug 2013, Thomas Zenker wrote:
>
>  On 08/16/13 15:41, Mikhail Tsatsenko wrote:
>>
>>> 2013/8/16 Thomas Zenker <thz at zenker.tk>:
>>>
>>>> Hi,
>>>>
>>>> after updating my freebsd amd64 box from 9.1 (r250841) to 9.2-RC
>>>> (r254276) virtualbox crashes the machine. Seconds after starting VBOX
>>>>
>>> After starting VBOX gui or guest machine? If first, try to rebuild
>>> userland portion of vbox too.
>>>
>>
>>         After starting a virtual guest machine in the GUI or directly
>> from cli
>> leads to the crash. The userland has been rebuild w/ 9.2 also. The same
>> binaries of the userland portion built with 9.2 work w/o problems in 9.1.
>>
>
> Updated to 9.2-PRERELEASE #0 r254408 amd64 today, rebuilt and reloaded the
> VirtualBox kernel module, and just started a couple of guests from the GUI
> with no problems.
>

Updated to r254416 today.Two crashes when I tried starting VirtualBox
4.16_2. I have both dumps and they ere very different. The first was a
"spin lock held too long" and the second was a general protection fault.
Both occurred when I attempted to start a saved Windows 7 VM.

FreeBSD rogue.local 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r254416M: Fri
Aug 16 11:27:20 PDT 2013     root at rogue.local:/usr/obj/usr/src/sys/GENERIC
amd64

#0  doadump (textdump=<value optimized out>) at pcpu.h:234
234     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) #0  doadump (textdump=<value optimized out>) at pcpu.h:234
#1  0xffffffff80915c66 in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:449
#2  0xffffffff80916167 in panic (fmt=0x1 <Address 0x1 out of bounds>)
    at /usr/src/sys/kern/kern_shutdown.c:637
#3  0xffffffff80cfae80 in trap_fatal (frame=0x9, eva=<value optimized out>)
    at /usr/src/sys/amd64/amd64/trap.c:879
#4  0xffffffff80cfb691 in trap (frame=0xffffff8124900830)
    at /usr/src/sys/amd64/amd64/trap.c:605
#5  0xffffffff80ce4ac3 in calltrap ()
    at /usr/src/sys/amd64/amd64/exception.S:232
#6  0xffffffff80b86015 in vm_map_entry_splay (addr=984915968,
    root=0xfffffe002c9af200) at /usr/src/sys/vm/vm_map.c:832
#7  0xffffffff80b870f7 in vm_map_lookup_entry (map=0xfffffe007535b640,
    address=984915968, entry=0xffffff8124900970)
    at /usr/src/sys/vm/vm_map.c:1080
#8  0xffffffff80b8a5cc in vm_map_madvise (map=0xfffffe007535b640,
   start=984915968, end=985440256, behav=5) at /usr/src/sys/vm/vm_map.c:2050
#9  0xffffffff80b8d9e3 in sys_madvise (td=0xfffffe000549e920,
    uap=<value optimized out>) at /usr/src/sys/vm/vm_mmap.c:760
#10 0xffffffff80cfa62a in amd64_syscall (td=0xfffffe000549e920, traced=0)
    at subr_syscall.c:135
#11 0xffffffff80ce4da7 in Xfast_syscall ()
    at /usr/src/sys/amd64/amd64/exception.S:391
#12 0x000000002ce13dcc in ?? ()
Previous frame inner to this frame (corrupt stack?)

I can make the cores and text dumps available. kmod was rebuilt after the
upgrade.
-- 
R. Kevin Oberman, Network Engineer
E-mail: rkoberman at gmail.com