From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 13:46:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B76F1065670; Tue, 23 Feb 2010 13:46:41 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EC9A58FC08; Tue, 23 Feb 2010 13:46:39 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA24637; Tue, 23 Feb 2010 15:46:37 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B83DC3C.4080201@icyb.net.ua> Date: Tue, 23 Feb 2010 15:46:36 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: =?KOI8-R?Q?=F3=C1=CE=C5=CB_=E7=D5=D2=C9=CE?= References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.0-STABLE freeze X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 13:46:41 -0000 on 23/02/2010 12:03 Санек Гурин said the following: > FreeBSD freeze > > After update few weeks ago freebsd began to freeze from time to time. Can't find any reason in logs or other way. System may halt after an hour of work, or may work few days. Before halt it may respond to shell commands very-very slow.... > > MB: MSI P45 NEO3-FR. BIOS ATA configured as AHCI. JMicron ATA controller is disabled. > > % uname -a > FreeBSD wk.kiev.ua 8.0-STABLE FreeBSD 8.0-STABLE #3 r204163: Sun Feb 21 10:07:59 EET 2010 root@wk.kiev.ua:/usr/obj/usr/src/sys/GNRDBG amd64 > > Kernel Config: http://xdevs.com/wk/kernel_config.txt > dmesg output: http://xdevs.com/wk/dmesg.txt > > > panic: _mtx_lock_sleep: recursed on non-recursive mutex ATA state lock @ /usr/sys/dev/ata/ata-all.c:334 > > cpuid = 1 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff801e05c5a = db_trace_self_wrapper+0x2a > panic() at 0xffffffff8058d692 = panic+0x182 > _mtx_lock_sleep() at 0xffffffff8057ec52 = _mtx_lock_sleep+0x152 > _mtx_lock_flags() at 0xffffffff8057ed41 = _mtx_lock_flags+exe1 > ata_reinit() at 0xffffffff802723f3 = ata_reinit+0xb3 > ata_conn_event() at 0xffffffff80272b7e = ata_conn_event+0xe3 > taskqueue_run() at 0xffffffff805c9e01 = taskqueue_run+0x91 > taskqueue_thread_loop() at 0xffffffff805c9f8f = taskqueue_thread_loop+0x3f > fork_exit() at 0xffffffff80564f3a = fork_exit+0x12a > fork_trampoline() at 0xffffffff8085b84e = fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff80000b9d30, rbp = 0 --- > Uptime: 19s > Cannot dump. Device not defined or unavailable. > Automatic reboot in 15 seconds - press a key on the console to abort > VOP_STRATEGY: bp in not locked but should be I believe that this a (well known?) bug in ata driver: state_mtx is not initialized as recursive, but is used as such. E.g. it is locked in ata_conn_event and then ata_reinit locks it again. Of course, an external condition is needed to trigger ata_conn_event in the first place. -- Andriy Gapon