From owner-freebsd-current@FreeBSD.ORG Thu Mar 25 16:54:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0A5F16A50F; Thu, 25 Mar 2004 16:53:59 -0800 (PST) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3DD243D45; Thu, 25 Mar 2004 16:53:58 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i2Q0rv5v014728; Fri, 26 Mar 2004 11:53:57 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i2Q0rtGQ004578; Fri, 26 Mar 2004 11:53:56 +1100 Date: Fri, 26 Mar 2004 11:53:54 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: John Baldwin In-Reply-To: <200403251527.27658.jhb@FreeBSD.org> Message-ID: <20040326114225.M39632@gamplex.bde.org> References: <20040325113619.N56656@pcle2.cc.univie.ac.at> <200403251527.27658.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@FreeBSD.org cc: current@FreeBSD.org cc: Lukas Ertl Subject: Re: panic: mutex Giant not owned X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Fri, 26 Mar 2004 00:54:01 -0000 On Thu, 25 Mar 2004, John Baldwin wrote: > On Thursday 25 March 2004 05:39 am, Lukas Ertl wrote: > > Hi, > > > > I was dropped into DDB after a panic and tried to save a coredump with > > "call doadump", which resulted in a: > > > > panic: mutex Giant not owned in /usr/src/sys/cam/cam_xpt.c:3970 > > > > Second call to "doadump" succeeded, but savecore(8) couldn't save the core > > ('bad dump header' or something like this). > > Cute. I should fix mtx_assert() to just bail and not panic if panicstr is > already set. Er, the panic is correct. Panic dump code must not use normal locking, since then it won't work if it hits an unlockable lock. panic() usually recursively panics earlier, near the sync() in boot(), if it hits an unlocakable lock. Changing mtx_assert() to not panic if panicstr is set would be worse for this than for the panic dump part, since sync() is normal file system code that depends on normal locking for correctness. Bruce