From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 21:52:59 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC9A9106566C; Wed, 25 Jan 2012 21:52:59 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BBBBB8FC0A; Wed, 25 Jan 2012 21:52:54 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA14839; Wed, 25 Jan 2012 23:52:53 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RqAlx-0006vT-0A; Wed, 25 Jan 2012 23:52:53 +0200 Message-ID: <4F2079B3.80305@FreeBSD.org> Date: Wed, 25 Jan 2012 23:52:51 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Gleb Smirnoff References: <4F1D18A5.8010006@FreeBSD.org> <20120123130743.GI16676@glebius.int.ru> <4F1D6830.60602@FreeBSD.org> <20120123162410.GN16676@glebius.int.ru> <20120123162606.GO16676@FreeBSD.org> <4F1D8E2B.30800@FreeBSD.org> <20120123164659.GQ16676@glebius.int.ru> <4F1D9128.3030501@FreeBSD.org> <20120124115424.GX16676@glebius.int.ru> <4F1E9F5F.8080209@FreeBSD.org> <20120124123245.GZ16676@glebius.int.ru> In-Reply-To: <20120124123245.GZ16676@glebius.int.ru> X-Enigmail-Version: undefined Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:52:59 -0000 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