From owner-freebsd-current Wed Nov 20 15:53:42 2002 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 5EA3F37B401 for ; Wed, 20 Nov 2002 15:53:40 -0800 (PST) Received: from outel.org (outel.org [168.150.177.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AC0E43E88 for ; Wed, 20 Nov 2002 15:53:39 -0800 (PST) (envelope-from qumqats@outel.org) Received: from localhost (winxp [192.168.1.20]) by outel.org (8.12.6/8.12.6) with ESMTP id gAKNjTuE088533 for ; Wed, 20 Nov 2002 15:45:36 -0800 (PST) (envelope-from qumqats@outel.org) Date: Wed, 20 Nov 2002 15:45:26 -0800 From: "Joel M. Baldwin" 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: References: X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --On Wednesday, November 20, 2002 2:27 PM -0500 John Baldwin wrote: > > On 20-Nov-2002 Joel M. Baldwin wrote: >> --On Wednesday, November 20, 2002 12:01 PM -0500 Robert Watson >> 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 <>< 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