Date: Thu, 01 May 2003 10:27:20 -0600 From: Scott Long <scott_long@btc.adaptec.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h Message-ID: <3EB14AE8.1040902@btc.adaptec.com> In-Reply-To: <20030501.101409.57443470.imp@bsdimp.com> References: <XFMail.20030501101142.jhb@FreeBSD.org> <1721460000.1051803729@aslan.btc.adaptec.com> <20030501.101409.57443470.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh wrote: > In message: <1721460000.1051803729@aslan.btc.adaptec.com> > "Justin T. Gibbs" <gibbs@scsiguy.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EB14AE8.1040902>