tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Need help looking at kernel dump for "/netbsd: panic: lock error"



On Wed, Jan 09, 2013 at 10:15:39AM -0800, Hisashi T Fujinaka wrote:
 > NetBSD documentation just kind of pointed me at figuring out which
 > processes are running and looking at the backtrace. Well, the backtrace
 > just looks to me like it was printing out the error. I know I should
 > look at other frames, but not sure what I should be looking at.

 > #8  0xffffffff803faab7 in trap (frame=0xfffffe8038bc2840) at 
 > /usr/src/sys/arch/amd64/amd64/trap.c:568

...execution entered the kernel because of a processor exception.

 > #7  uvm_fault_internal (orig_map=<optimized out>, vaddr=<optimized out>, 
 > access_type=<optimized out>, fault_flag=<optimized out>)
 >     at /usr/src/sys/uvm/uvm_fault.c:877

...this is the entry point in the VM system for handling page faults.

 > #6  uvm_fault_check (maxprot=false, ranons=<optimized out>, 
 > flt=0xfffffe8038bc26e0, ufi=0xfffffe8038bc26a0)
 >     at /usr/src/sys/uvm/uvm_fault.c:957
 > #5  0xffffffff8043a933 in uvmfault_lookup (write_lock=false, 
 > ufi=0xfffffe8038bc26a0) at /usr/src/sys/uvm/uvm_fault_i.h:126

UVM goes to process the fault...

 > #4  0xffffffff8027d62f in rw_vector_enter (rw=0xfffffe8076e20198, 
 > op=RW_READER) at /usr/src/sys/kern/kern_rwlock.c:341

takes a lock...

 > #3  0xffffffff803bba6a in lockdebug_abort (lock=0xfffffe8076e20198, 
 > ops=0xffffffff806ecaa0,
 >     func=0xffffffff804d73c0 "rw_vector_enter", msg=0xffffffff8051a7a7 
 > "locking against myself")
 >     at /usr/src/sys/kern/subr_lockdebug.c:858
 > #2  0xffffffff803c2159 in panic (fmt=<unavailable>) at 
 > /usr/src/sys/kern/subr_prf.c:205
 > #1  0xffffffff803c2084 in vpanic (fmt=0xffffffff8053631d "lock error", 
 > ap=0xfffffe8038bc2410) at /usr/src/sys/kern/subr_prf.c:308

and lockdebug alerts us to the fact that the same kernel thread (lwp)
is holding this lock already.

Further analysis requires wading into uvmfault_lookup to try to figure
out exactly how this happened. Since you appear to have debug info
this probably won't be that hard.

-- 
David A. Holland
dholland%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index