I'm a bit confused by the following lock order reversal. My box started by locking in 7.1-PRERELEASE. However, with debugging and WITNESS, I saw the LOR, but the console still became unresponsive. I upgraded to CURRENT #0: Thu Nov 27 17:51:41 PST 2008, and the problem still persists. I'm not sure what exactly is happening, or how to debug it further. Actually, by triggering some sort of console message (removing a usb device, triggering an acpi error with my power switch) I can see the keyboard input and console output, but it really doesn't work very well. Essentially, at that point a hard powerdown is all I can do. kernel: lock order reversal: kernel: 1st 0xffffff000c7f3550 rtentry (rtentry) _at_ /mnt/src/sys/net/route.c:333 kernel: 2nd 0xffffff0004e82af8 radix node head (radix node head) _at_ /mnt/src/sys/net/route.c:887 kernel: KDB: stack backtrace: kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kernel: _witness_debugger() at _witness_debugger+0x2e kernel: witness_checkorder() at witness_checkorder+0x81e kernel: _mtx_lock_flags() at _mtx_lock_flags+0x78 kernel: rtrequest1_fib() at rtrequest1_fib+0x8f kernel: rtredirect_fib() at rtredirect_fib+0x28e kernel: icmp_input() at icmp_input+0x3b1 kernel: ip_input() at ip_input+0xc0 kernel: ether_demux() at ether_demux+0x1ed kernel: ether_input() at ether_input+0x1d5 kernel: em_rxeof() at em_rxeof+0x200 kernel: em_handle_rxtx() at em_handle_rxtx+0x4b kernel: taskqueue_run() at taskqueue_run+0x96 kernel: taskqueue_thread_loop() at taskqueue_thread_loop+0x55 kernel: fork_exit() at fork_exit+0x12a kernel: fork_trampoline() at fork_trampoline+0xe kernel: --- trap 0, rip = 0, rsp = 0xfffffffe400bcd40, rbp = 0 ---Received on Fri Nov 28 2008 - 21:46:06 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:38 UTC