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 [email protected]
