From owner-cvs-src@FreeBSD.ORG Wed Mar 3 11:35:42 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F12C16A4D3 for ; Wed, 3 Mar 2004 11:35:42 -0800 (PST) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2171E43D3F for ; Wed, 3 Mar 2004 11:35:42 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 30533 invoked from network); 3 Mar 2004 19:35:41 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 3 Mar 2004 19:35:41 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i23JZK2B088763; Wed, 3 Mar 2004 14:35:34 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Wed, 3 Mar 2004 14:35:23 -0500 User-Agent: KMail/1.6 References: <200403021502.i22F28vF032585@repoman.freebsd.org> <200403021708.43422.jhb@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200403031435.23839.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern subr_sleepqueue.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2004 19:35:42 -0000 On Tuesday 02 March 2004 09:02 pm, Dag-Erling Sm=F8rgrav wrote: > John Baldwin writes: > > I never saw that case and this is the first I've heard of it. ddb tends > > to freeze when you enter it holding a spin lock. Do you have any log > > messages from the mis-matched locks for msleep? > > Mismatched locks to msleep(0xc9376000, pause): > old 0xc935d06c (process lock), new 0xc64d1e2c (process lock) > Stack backtrace: > sleepq_add(c748cdc0,c9376000,c64d1e2c,c05bbdf1,0) at sleepq_add+0x1ee > msleep(c9376000,c64d1e2c,168,c05bbdf1,0) at msleep+0x19f > kern_sigsuspend(c64d23f0,0,0,0,0) at kern_sigsuspend+0xa1 > linux_rt_sigsuspend(c64d23f0,ebb20d14,2,279b5,200212) at > linux_rt_sigsuspend+0x4f syscall(2f,bfbf002f,bfbf002f,28636da8,bfbfe0c0) = at > syscall+0x129 > Xint0x80_syscall() at Xint0x80_syscall+0x1d > --- syscall (179), eip =3D 0x288379b6, esp =3D 0xbfbfe0a0, ebp =3D 0xbfbf= e0a8 --- > > DES I see the bug. Here are the msleep's on p_sigacts: > grep msleep kern_sig.c error =3D msleep(ps, &p->p_mtx, PPAUSE|PCATCH, "sigwait", hz); while (msleep(p->p_sigacts, &p->p_mtx, PPAUSE|PCATCH, "pause", 0) = =3D=3D=20 0) while (msleep(p->p_sigacts, &p->p_mtx, PPAUSE|PCATCH, "opause", 0) = =3D=3D=20 0) Now realize that p_sigacts is a refcount'd struct shared between rfork'd=20 processes (i.e. Linux threads). The sleep's don't actually get woken up vi= a=20 a wakeup, they get woken up via a signal, so the wait channel is really a=20 dummy. Try changing those three msleep's to sleep on &ps and &p->p_sigacts= =20 and see if that fixes the panic. =2D-=20 John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =3D http://www.FreeBSD.org