FBSD 9.2 RC crashes running as virtualbox host

[Kevin Oberman]

On Fri, Aug 16, 2013 at 10:44 PM, Kevin Oberman <rkoberman at gmail.com> wrote:

> 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.
>

Just confirmed that 254050 works fine. Trying 354162 and will continue
binary hunt till I find it.
-- 
R. Kevin Oberman, Network Engineer
E-mail: rkoberman at gmail.com