Date: Wed, 20 Nov 2002 15:45:26 -0800 From: "Joel M. Baldwin" <qumqats@outel.org> Cc: current@FreeBSD.org Subject: Re: panic: sleeping thread owns a mutex - with debug traceback Message-ID: <9917049.1037807126@[192.168.1.20]> In-Reply-To: <XFMail.20021120142746.jhb@FreeBSD.org> References: <XFMail.20021120142746.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--On Wednesday, November 20, 2002 2:27 PM -0500 John Baldwin <jhb@FreeBSD.org> wrote: > > On 20-Nov-2002 Joel M. Baldwin wrote: >> --On Wednesday, November 20, 2002 12:01 PM -0500 Robert Watson >> <rwatson@FreeBSD.ORG> wrote: >> >>> On Wed, 20 Nov 2002, Robert Watson wrote: >>> >>>> Hmm. Another thread has decided to sleep while holding an inpcb >>>> mutex. Any chance this can be reproduced while running WITNESS? >>>> If so, you should get a panic earlier when the other thread sleeps >>>> in the first place. The easiest way to do that is if you can >>>> reproduce the panic with WITNESS. If you can't reproduce the >>>> panic, you may be able to extract this from your system core using >>>> gdb -- you want to figure out what the thread owner of the mutex >>>> is doing -- in the context of the kassert() below, td is the >>>> pointer to the thread that owns the mutex. I'm not sure how to >>>> extract a stack trace from that information, unfortunately, >>>> perhaps someone can give us pointers. (note: td from the >>>> priority_propagate() argument is shadowed, which is annoying). >>> >>> Ack. I mis-read. You want the stack from thread td1 (the mutex >>> owner), not thread td. >> >> The kernel that produced the core dump ALREADY HAS >> WITNESS and WITNESS_SKIPSPIN! :( >> >> I'll try to get more info from kgdb, but I doubt that I'll have >> much luck since I've never tried using gdb before. > > Erm. Did you manage to look at dmesg then? If so, you would have > seen warnings from WITNESS earlier about the locks messing up. If I see NOTHING in the dmesg about locks. > you can reproduce this and are letting it sit unattended, a better > plan might be to turn on witness_ddb (it's a kernel option, loader > tunable, and sysctl (debug.witness_ddb)) and then when the original > error occurs it will drop into the debugger with a very useful error > message. You can also get a useful trace at that point from ddb. I have debug.witness_ddb=1 and will try to panic the system. I'll let you know what happens. > -- > > John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9917049.1037807126>