new panic in cpu_reset() with WITNESS
Andriy Gapon
avg at FreeBSD.org
Wed Jan 25 21:52:59 UTC 2012
on 24/01/2012 14:32 Gleb Smirnoff said the following:
> Yes, now:
>
> Rebooting...
> lock order reversal:
> 1st 0xffffffff80937140 smp rendezvous (smp rendezvous) @ /usr/src/head/sys/kern/kern_shutdown.c:542
> 2nd 0xfffffe0001f5d838 uart_hwmtx (uart_hwmtx) @ /usr/src/head/sys/dev/uart/uart_cpu.h:92
> panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ /usr/src/head/sys/kern/kern_cons.c:500
OK, so it's just a plain LOR between smp rendezvous and uart_hwmtx, no new
details...
It's still intriguing to me why the LOR *doesn't* happen [*] with
stop_scheduler_on_panic=0. But I don't see a productive way to pursue this
investigation further.
[*] - or maybe better to say why it isn't detected/reported.
> cpuid = 0
> KDB: enter: panic
> [ thread pid 1 tid 100001 ]
> Stopped at kdb_enter+0x3b: movq $0,0x5159f2(%rip)
> db> bt
> Tracing pid 1 tid 100001 td 0xfffffe0001d5e000
> kdb_enter() at kdb_enter+0x3b
> panic() at panic+0x1c7
> _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x10f
> cnputs() at cnputs+0x7a
> putchar() at putchar+0x11f
> kvprintf() at kvprintf+0x83
> vprintf() at vprintf+0x85
> printf() at printf+0x67
Maybe kdb_backtrace ought to use db_printf.
> kdb_backtrace() at kdb_backtrace+0x2d
> _witness_debugger() at _witness_debugger+0x2c
> witness_checkorder() at witness_checkorder+0x854
> _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x99
> uart_cnputc() at uart_cnputc+0x3e
> cnputc() at cnputc+0x4c
> cnputs() at cnputs+0x26
> putchar() at putchar+0x11f
> kvprintf() at kvprintf+0x83
> vprintf() at vprintf+0x85
> printf() at printf+0x67
> cpu_reset() at cpu_reset+0x81
> kern_reboot() at kern_reboot+0x3a5
> sys_reboot() at sys_reboot+0x42
> amd64_syscall() at amd64_syscall+0x39e
> Xfast_syscall() at Xfast_syscall+0xf7
> --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40ea3c, rsp = 0x7fffffffd6d8, rbp = 0x49 ---
--
Andriy Gapon
More information about the freebsd-current
mailing list