From owner-freebsd-current Wed Nov 20 11:27:49 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 94A9837B401 for ; Wed, 20 Nov 2002 11:27:47 -0800 (PST) Received: from mail.speakeasy.net (mail16.speakeasy.net [216.254.0.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCD6943E6E for ; Wed, 20 Nov 2002 11:27:46 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 6015 invoked from network); 20 Nov 2002 19:27:53 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail16.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 20 Nov 2002 19:27:53 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id gAKJRj2D035505; Wed, 20 Nov 2002 14:27:45 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <2964362.1037787636@[192.168.1.20]> Date: Wed, 20 Nov 2002 14:27:46 -0500 (EST) From: John Baldwin To: "Joel M. Baldwin" Subject: Re: panic: sleeping thread owns a mutex - with debug traceback Cc: current@FreeBSD.ORG, Robert Watson 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 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 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 <>< 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