From owner-cvs-src@FreeBSD.ORG Thu May 1 09:30:57 2003 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 493D237B401; Thu, 1 May 2003 09:30:57 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EE6043F75; Thu, 1 May 2003 09:30:56 -0700 (PDT) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h41GRZZ22947; Thu, 1 May 2003 09:27:35 -0700 Received: from btc.btc.adaptec.com ([10.100.0.52]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id JAA11256; Thu, 1 May 2003 09:30:27 -0700 (PDT) Received: from btc.adaptec.com (hollin [10.100.253.56]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id KAA03365; Thu, 1 May 2003 10:30:23 -0600 (MDT) Message-ID: <3EB14AE8.1040902@btc.adaptec.com> Date: Thu, 01 May 2003 10:27:20 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <1721460000.1051803729@aslan.btc.adaptec.com> <20030501.101409.57443470.imp@bsdimp.com> In-Reply-To: <20030501.101409.57443470.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: src-committers@freebsd.org cc: gallatin@cs.duke.edu cc: jhb@freebsd.org cc: gibbs@scsiguy.com cc: cvs-src@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h 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: Thu, 01 May 2003 16:30:57 -0000 M. Warner Losh wrote: > In message: <1721460000.1051803729@aslan.btc.adaptec.com> > "Justin T. Gibbs" writes: > : >> This means that all detaches must occur from a context that can > : >> sleep, but that shouldn't be too hard to make happen. > : > > : > People can't hold the driver lock across bus_teardown_intr() with this > : > model, which does require a possibly smarter interrupt routine or > : > maybe a better detach that only disables interrupts then does a teardown, > : > then finishes shutting down the rest of the hardware along with an > : > interrupt handler that doesn't re-enable interrupts in the shutdown case. > : > : All doable things for all but really broken hardware. fxp is not broken. > > The whole reason for the gone flag may be misunderstood here. You can > easily turn off the fxp device, and there will be no more interrupts > from it. However, its ISR can and will still be called from time to > time until the bus_teardown_intr() is complete? Why you ask? Because > of shared interrupts. If fxp shares an interrupt with another device, > your ISR will execute even if you write 0 into the interrupt enable > register if that other device gets an interrupt between the time you > write to this register and the time bus_teardown_intr is called, even > on a single CPU machine: > > > fxp_detach() > [4] LOCK > [a] write 0 to dis intr > [5] device B on same intr interrupts here > fxp_intr() > LOCK (->sleep) > [b] gone = 0; > UNLOCK > [1] if (gone) return; > [2] bus_teardown_intr(); > [3] bus_teardown_intr returns > > > [1] and [2] can happen in any order, but you know both of them have > happened by [3]. > > The order of [a] and [b] don't really matter because fxp (or anything > that shares its interrupt) could generate an interrupt after the lock > is taken out at [4] and you'd still have a fxp_intr sleeping thread. > The important thing is that an interrupt[5] happens after [4]. This > can happen on both the single CPU case and the SMP case. > > This might argue for blocking interrupts during a device detach. I > think there might be problems with that apprach as well, although I'd > have to think about it a bit to be sure. > > Warner In this example, is there a reason for the fxp ISR to hold the mutex before it determines the source of the interrupt? Scott