From owner-freebsd-current Wed May 16 20:36:32 2001 Delivered-To: freebsd-current@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 41AEF37B422; Wed, 16 May 2001 20:36:27 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f4H3aRM57804; Wed, 16 May 2001 20:36:27 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id D33BC3811; Wed, 16 May 2001 20:36:26 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: John Baldwin Cc: Matthew Jacob , current@FreeBSD.ORG, Bob Bishop Subject: Re: panic: sleeping process owns a mutex In-Reply-To: Date: Wed, 16 May 2001 20:36:26 -0700 From: Peter Wemm Message-Id: <20010517033626.D33BC3811@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin wrote: > > On 16-May-01 Matthew Jacob wrote: > > > > Oh, I'd like you to think twice about this. Massive amounts of driver > > rototilling should be avoided at this point. > > Well, it's causing panics in some cases. Those are bad. Basically I would b e > reverting earlier changes. For most of the drivers it is farly low impact. Simply replace things like this: #define FOO_LOCK(sc) mtx_lock(sc->sc_mtx); #define FOO_UNLOCK(sc) mtx_unlock(sc->sc_mtx); with: #if 0 #define FOO_LOCK(sc) mtx_lock(sc->sc_mtx); #define FOO_UNLOCK(sc) mtx_unlock(sc->sc_mtx); #else #define FOO_LOCK(sc) #define FOO_UNLOCK(sc) #endif That should at least discourage more cut/paste of the same broken locking logic into new drivers. > > On Wed, 16 May 2001, John Baldwin wrote: > > > >> > >> On 16-May-01 Bob Bishop wrote: > >> > Hi, > >> > > >> > This while building world, with a kernel cvsup at Fri Apr 27 04:06:40 BS T > >> > 2001 > >> > > >> > kern/kern_synch.c:386 sleeping with "vr0" locked from pci/if_vr.c:1315 > >> > > >> > abridged backtrace: > >> > > >> > panic() > >> > propagate_priority() > >> > _mtx_lock_sleep() > >> > vr_intr() > >> > ithread_loop() > >> > fork_exit() > >> > fork_trampoline() > >> > >> Well, I think the best thing to do for now will be to back out all the > >> ethernet > >> driver locking until we figure out how we are actually going to lock them. > >> The original locks that went in starting with fxp many months ago weren't > >> quite > >> right but have been mostly harmless up to this point. There are some cas es > >> where we sleep with locks however, which can lead to problems. > >> > >> -- > >> > >> John Baldwin -- http://www.FreeBSD.org/~jhb/ > >> PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > >> "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 > >> > > > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "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 > > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message