Bug #1676
closed
tmpfs fsstress panic
0%
Description
tmpfs panic-ed on an fsstress run fairly quickly; the tmpfs volume was limited
to 256MB, the VM had 512MB of RAM and 512MB of swap. I was unable to grab
coredumps, since there is no dump device configured yet.
I'm somewhat confused by the backtrace; tmpfs_nrename doesn't take more than 1
argument and it never directly calls lockmgr; vn_lock does...
Panic:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x6c
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0312fd5
stack pointer = 0x10:0xcca55b3c
frame pointer = 0x10:0xcca55b4c
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, IOPL = 0
current process = 882 (fsstress)
current thread = pri 6
kernel: type 12 trap, code=0
Stopped at lockmgr+0x8b: movl 0x4(%ebx),%ecx
db> where
lockmgr(68,6,cca55b78,c0378bfb,c9ef2ba0) at lockmgr+0x8b
tmpfs_nrename(cca55bc0,cca55bb4,c9e2a2b4,c9e2a2b4,c1756d70) at tmpfs_rename+0x9
vop_nrename(c1753e30,cca55c80,cca55c48,ccad7ce8,ccad9c28) at vop_nrename+0x55
kern_rename(cca55c80,cca55c48,ccaaecd8,c9e2a098,c15c63f8) at kern_rename+0x273
sys_rename(cca55cf0,6,f4cb,0,c9e2cd98) at sys_rename+0x45
syscall2(cca55d40) at syscall2+0x20e
Xint0x80_syscall() at Xint0x80_syscall+0x36
db>
Updated by dillon almost 15 years ago
:New submission from Venkatesh Srinivas <me@acm.jhu.edu>:
:
:tmpfs panic-ed on an fsstress run fairly quickly; the tmpfs volume was limited
:to 256MB, the VM had 512MB of RAM and 512MB of swap. I was unable to grab
:coredumps, since there is no dump device configured yet.
:
:I'm somewhat confused by the backtrace; tmpfs_nrename doesn't take more than 1
:argument and it never directly calls lockmgr; vn_lock does...
We're gonna start needing kernel dumps to really track these down.
If you send me a private email with your ssh public key and prefered
username I will set up a leaf.dragonflybsd.org shell account for
you that you can upload cores into.-Matt
Updated by vsrinivas almost 15 years ago
I repeated this on another VM, with 768MB of RAM and 2GB of swap. This time, I
was able to get a coredump.
Updated by dillon almost 15 years ago
:Venkatesh Srinivas <me@acm.jhu.edu> added the comment:
:
:I repeated this on another VM, with 768MB of RAM and 2GB of swap. This time, I
:was able to get a coredump.
:
:http://endeavour.zapto.org/dfly/tmpfs_panic.20100218/
This was a bug in the tmpfs_rename() code which I fixed late yesterday.-Matt