virtualbox status on 8.0-STABLE i386
Alexander Eichner
alexeichi at yahoo.de
Sun Mar 7 14:55:32 UTC 2010
Hi,
can you try the attached patch please?
This should fix the panic you encountered. Please undo your kernel
changes befoer testing.
Thanks.
Regards,
Alexander Eichner
Mikolaj Golub wrote:
> Hi,
>
> Recently I have updated my 8.0-STABLE i386 system and have learnt that
> virtualbox begins to crash my box with the error
>
> panic: vm_fault: fault on nofault entry, addr: c1608000
>
> (kgdb) bt
> #0 doadump () at pcpu.h:246
> #1 0xc04ec379 in db_fncall (dummy1=-1064468854, dummy2=0, dummy3=-1, dummy4=0xe865d5bc "пуeХ")
> at /usr/src/sys/ddb/db_command.c:548
> #2 0xc04ec7af in db_command (last_cmdp=0xc0e04c9c, cmd_table=0x0, dopager=0)
> at /usr/src/sys/ddb/db_command.c:445
> #3 0xc04ec864 in db_command_script (command=0xc0e05bc4 "call doadump")
> at /usr/src/sys/ddb/db_command.c:516
> #4 0xc04f09a0 in db_script_exec (scriptname=0xe865d6c8 "kdb.enter.panic", warnifnotfound=Variable "warnifnotfound" is not available.
> )
> at /usr/src/sys/ddb/db_script.c:302
> #5 0xc04f0a87 in db_script_kdbenter (eventname=0xc0cc248d "panic") at /usr/src/sys/ddb/db_script.c:324
> #6 0xc04ee768 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:228
> #7 0xc08d7d06 in kdb_trap (type=3, code=0, tf=0xe865d804) at /usr/src/sys/kern/subr_kdb.c:535
> #8 0xc0beb39b in trap (frame=0xe865d804) at /usr/src/sys/i386/i386/trap.c:690
> #9 0xc0bccd0b in calltrap () at /usr/src/sys/i386/i386/exception.s:165
> #10 0xc08d7e8a in kdb_enter (why=0xc0cc248d "panic", msg=0xc0cc248d "panic") at cpufunc.h:71
> #11 0xc08a88b6 in panic (fmt=0xc0cecbc4 "vm_fault: fault on nofault entry, addr: %lx")
> at /usr/src/sys/kern/kern_shutdown.c:562
> #12 0xc0b0c3d7 in vm_fault (map=0xc1990000, vaddr=3244326912, fault_type=Variable "fault_type" is not available.
> )
> at /usr/src/sys/vm/vm_fault.c:283
> #13 0xc0bea7d6 in trap_pfault (frame=0xe865dac0, usermode=0, eva=3244330720)
> at /usr/src/sys/i386/i386/trap.c:840
> #14 0xc0beb225 in trap (frame=0xe865dac0) at /usr/src/sys/i386/i386/trap.c:533
> #15 0xc0bccd0b in calltrap () at /usr/src/sys/i386/i386/exception.s:165
> #16 0xc12beed0 in rtR0MemObjNativeGetPagePhysAddr (pMem=0xc5ed3110, iPage=0) at pmap.h:300
> #17 0xc12ac354 in SUPR0LockMem (pSession=0xc5c61c10, pvR3=695959552, cPages=1, paPages=0xc5f83668)
> at SUPDrv.c:2307
> #18 0xc12ac8cb in supdrvIOCtl (uIOCtl=536892942, pDevExt=0xc12c9ac0, pSession=0xc5c61c10,
> pReqHdr=0xc5f83650) at SUPDrv.c:1245
> #19 0xc12b0c3a in VBoxDrvFreeBSDIOCtl (pDev=0xc665d800, ulCmd=536892942,
> pvData=0xe865dd00 "ю8 )\003╬кюq\002", fFile=3, pTd=0xc69556f0)
> at /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-3.1.2_OSE/out/freebsd.x86/debug/bin/src/vboxdrv/freebsd/SUPDrv-freebsd.c:505
> #20 0xc0829658 in devfs_ioctl_f (fp=0xc670fa80, com=536892942, data=0xe865dd00, cred=0xc6bbeb00,
> td=0xc69556f0) at /usr/src/sys/fs/devfs/devfs_vnops.c:659
> #21 0xc08eec8d in kern_ioctl (td=0xc69556f0, fd=7, com=536892942, data=0xe865dd00 "ю8 )\003╬кюq\002")
> at file.h:262
> #22 0xc08eee14 in ioctl (td=0xc69556f0, uap=0xe865dcf8) at /usr/src/sys/kern/sys_generic.c:678
> #23 0xc0beaad0 in syscall (frame=0xe865dd38) at /usr/src/sys/i386/i386/trap.c:1111
> #24 0xc0bccda0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261
> #25 0x00000033 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb) fr 16
> #16 0xc12beed0 in rtR0MemObjNativeGetPagePhysAddr (pMem=0xc5ed3110, iPage=0) at pmap.h:300
> 300 pa = (pa & PG_FRAME) | (va & PAGE_MASK);
> (kgdb) list
> 295 * access the PTE because it would use the new PDE. It is,
> 296 * however, safe to use the old PDE because the page table
> 297 * page is preserved by the promotion.
> 298 */
> 299 pa = KPTmap[i386_btop(va)];
> 300 pa = (pa & PG_FRAME) | (va & PAGE_MASK);
> 301 }
> 302 return (pa);
> 303 }
> 304
>
> There were some changes in this part recently (r203182):
>
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/include/pmap.h.diff?r1=1.140.2.2;r2=1.140.2.3;only_with_tag=RELENG_8
>
> So I removed KPTmap[i386_btop(va)] with *vtopte(va) and have working
> virtualbox again, but I suppose this is rather the problem with virualbox and
> not with the kernel code.
>
> In February Alexander Eichner posted the patch to freebsd-emulation@ (thread
> with the subject "Patch to fix VirtualBox with recent kernel versions"):
>
> http://lists.freebsd.org/pipermail/freebsd-emulation/2010-February/007434.html
>
> But it does not fix my panics. The patch adds additional handling in
> rtR0MemObjNativeGetPagePhysAddr() for the case
> pMem.enmType == RTR0MEMOBJTYPE_MAPPING, while I am observing the panics
> for pMem.enmType == RTR0MEMOBJTYPE_LOCK:
>
> (kgdb) fr 17
> #17 0xc12ac354 in SUPR0LockMem (pSession=0xc5c61c10, pvR3=695959552, cPages=1, paPages=0xc5f83668)
> at SUPDrv.c:2307
> 2307 paPages[iPage] = RTR0MemObjGetPagePhysAddr(Mem.MemObj, iPage);
> (kgdb) p Mem.MemObj.enmType
> $1 = RTR0MEMOBJTYPE_LOCK
>
> So, it looks like some additional handling should be added for this case...
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: memobj_lockuser_fix.patch
Type: text/x-patch
Size: 800 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100307/a3d89454/memobj_lockuser_fix.bin
More information about the freebsd-stable
mailing list