From owner-freebsd-current Tue Jan 7 8:41:30 2003 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 503C737B401 for ; Tue, 7 Jan 2003 08:41:29 -0800 (PST) Received: from mail.speakeasy.net (mail17.speakeasy.net [216.254.0.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id C970043ED1 for ; Tue, 7 Jan 2003 08:41:28 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 19216 invoked from network); 7 Jan 2003 16:41:31 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail17.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 7 Jan 2003 16:41:31 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id h07GfQUT080247; Tue, 7 Jan 2003 11:41:26 -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: <20030106031821.GA92908@goddamnbastard.org> Date: Tue, 07 Jan 2003 11:41:33 -0500 (EST) From: John Baldwin To: ryan beasley Subject: Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/s Cc: current@freebsd.org 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 06-Jan-2003 ryan beasley wrote: > On Sun, Jan 05, 2003 at 08:54:01PM -0600, ryan beasley wrote: >> I'm including a GDB capture including traceback and some locking >> information. Anyone have any ideas? Is there any other data I should >> grab and submit? > > I'm really sorry for following up to myself again, but the following > might be useful: > > (gdb) >#8 0xc01bce28 in enroll (description=0xc02e3718 "vnode interlock", > lock_class=0xc0300fc0) > at /home/ryanb/FREDRIK_DP_INV/sys/kern/subr_witness.c:985 > 985 if (w->w_name == description || (w->w_refcount > 0 && > Current language: auto; currently c > (gdb) p *w > $16 = {w_name = 0xc16fd8fe
, > w_class = 0xc0300fc0, w_list = {stqe_next = 0xc032fa50}, w_typelist = { > stqe_next = 0xc032fa50}, w_children = 0x0, w_file = 0x0, w_line = 0, > w_level = 0, w_refcount = 2, w_Giant_squawked = 0 '\0', > w_other_squawked = 0 '\0', w_same_squawked = 0 '\0'} > > This is the instruction where the page fault occurred. As to how w_name > was clobbered, I have no idea. Your 3rd party registered a lock somehow? Does it do mtx_init() and not do mtx_destroy() when being unloaded? -- 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