Bug #2129
openDFBSD v2.11.0.661.gf9438 i386 - panic: lockmgr thrd_sleep
0%
Description
Hi,
I just got this panic while doing nothing special. A couple ssh sessions to IRC,
and one vkernel running:
I can provide the kernel core on demand.
Cheers,
Antonio Huete
-------------
panic: lockmgr thrd_sleep from 0xc056759b: called from interrupt, ipi, or hard
code section
cpuid = 1
Trace beginning at frame 0xd566eac0
panic(ffffffff,1,c06d8378,d566eaf4,c07fc24c) at panic+0x198
panic(c06d8378,c06a9ecd,c056759b,d566eb38,d566eb44) at panic+0x198
lockmgr(c0850744,1,8,0,c064ab09) at lockmgr+0x55
vm_map_lookup(d566ebcc,deadc000,1,d566ebd0,d566ebc4) at vm_map_lookup+0x46
vm_fault(c0850700,deadc000,1,0,c0850700) at vm_fault+0x82
trap_pfault(c062b084,d566ec4c,c0611af0,c55d6000,deadc102) at trap_pfault+0xf8
trap(d566ec88) at trap+0x5ab
calltrap() at calltrap+0xd
--- trap 0, eip = 0, esp = 0x10246, ebp = 0xdeadc0de ---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 01000000
fault virtual address = 0xdeadc0e2
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0603e47
stack pointer = 0x10:0xd566e9f4
frame pointer = 0x10:0xd566e9fc
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = Idle
current thread = pri 14 (CRIT)
<- SMP: XXX
trap number = 12
panic: page fault
cpuid = 1
boot() called on cpu#1
Uptime: 2h11m50s
Physical memory: 2006 MB
Dumping 336 MB: 321 305 289 273 257 241 225 209 193 177 161 145 129 113 97 81 65
49 33 17 1
Files
Updated by tuxillo over 13 years ago
I've activated DEBUG_LOCKS to see if I can catch exactly from where this happens.
Actually I don't have a way to reproduce it easily.
Updated by tuxillo over 13 years ago
Hi,
I got it:
panic: lockmgr thrd_sleep from /home/source/dfbsd/sys/vm/vm_map.c:3598: called
from interrupt, ipi, or hard code section
cpuid = 1
Trace beginning at frame 0xd4367a98
panic(ffffffff,1,c06fd84c,d4367acc,c08443ac) at panic+0x198
panic(c06fd84c,c06cdfb4,c071c114,e0e,d4367b18) at panic+0x198
debuglockmgr(c089db84,1,c069fc8a,c071c114,e0e) at debuglockmgr+0x59
vm_map_lookup(d4367bb8,deadc000,1,d4367bbc,d4367bb0) at vm_map_lookup+0x5e
vm_fault(c089db40,deadc000,1,0,c089db40) at vm_fault+0x82
trap_pfault(e3,0,d4367c60,c03865fb,0) at trap_pfault+0xf8
trap(d4367c78) at trap+0x5db
calltrap() at calltrap+0xd
--- trap 0, eip = 0, esp = 0x10246, ebp = 0xdeadc0de ---
Line 3598 is a vm_map_lock_read.
3596 RetryLookup:
3597 if (use_read_lock)
3598 vm_map_lock_read(map);
Cheers,
Antonio Huete
Updated by vsrinivas over 13 years ago
Hi,
Could you post the kernel core from the DEBUG_LOCKS run?
Thanks,
-- vs
Updated by ahuete.devel over 13 years ago
Venk,
The kernel core that I got is without DEBUG_LOCKS. Further panics with it in
it doesn't dump.
Cheers,
Antonio Huete
2011/9/5 Venkatesh Srinivas (via DragonFly issue tracker) <
sinknull@leaf.dragonflybsd.org>
Venkatesh Srinivas <vsrinivas@dragonflybsd.org> added the comment:
Hi,
Could you post the kernel core from the DEBUG_LOCKS run?
Thanks,
-- vs_____________________________________________
DragonFly issue tracker <bugs@lists.dragonflybsd.org>
<http://bugs.dragonflybsd.org/issue2129>
_____________________________________________