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