Date: Wed, 20 Nov 2002 14:27:46 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: "Joel M. Baldwin" <qumqats@outel.org> Cc: current@FreeBSD.ORG, Robert Watson <rwatson@FreeBSD.ORG> Subject: Re: panic: sleeping thread owns a mutex - with debug traceback Message-ID: <XFMail.20021120142746.jhb@FreeBSD.org> In-Reply-To: <2964362.1037787636@[192.168.1.20]>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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. -- 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?XFMail.20021120142746.jhb>