Date: Fri, 26 Mar 2004 11:53:54 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: John Baldwin <jhb@FreeBSD.org> Cc: Lukas Ertl <le@FreeBSD.org> Subject: Re: panic: mutex Giant not owned Message-ID: <20040326114225.M39632@gamplex.bde.org> In-Reply-To: <200403251527.27658.jhb@FreeBSD.org> References: <20040325113619.N56656@pcle2.cc.univie.ac.at> <200403251527.27658.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040326114225.M39632>