From owner-freebsd-fs@FreeBSD.ORG Tue Feb 2 17:43:01 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 178DB106566B; Tue, 2 Feb 2010 17:43:01 +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 2801E8FC2A; Tue, 2 Feb 2010 17:42:59 +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 TAA20962; Tue, 02 Feb 2010 19:42:54 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B68641D.9000201@icyb.net.ua> Date: Tue, 02 Feb 2010 19:42:53 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Julian Elischer References: <4B682972.6030604@darkbsd.org> <4B682F29.90505@icyb.net.ua> <4B686324.2090308@elischer.org> In-Reply-To: <4B686324.2090308@elischer.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Stephane LAPIE , freebsd-hardware@freebsd.org Subject: Re: [zfs][hardware] Reproducible kernel panic in 8.0-STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 17:43:01 -0000 on 02/02/2010 19:38 Julian Elischer said the following: > Andriy Gapon wrote: >> on 02/02/2010 15:32 Stephane LAPIE said the following: >>> I have a case of kernel panic that can be consistently reproduced, and >>> which I guess is related to the hardware I'm using (Marvell controllers, >>> check my pciconf -lv output below). >>> >>> The kernel panic message is always, consistently, the following : >>> >>> Sleeping thread (tid 100021, pid 0) owns a non-sleepable lock >> >> I probably won't be able to help you, but to kickstart debugging could >> you please >> run 'procstat -t 0' and determine what kernel thread has tid 100021 on >> your system? > > or in the kernel debugger after the panic, do: bt I think that in this case it may not help. I mean the stack trace. Because, I think that this panic happens after the taskqueue thread is done with its tasks and is parked waiting. > you DO have options kdb and ddb right? (I never leave home without them) > -- Andriy Gapon