Date: Thu, 01 May 2003 10:38:30 -0600 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: gallatin@cs.duke.edu Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h Message-ID: <1742240000.1051807110@aslan.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
> : 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? No, I didn't ask. The same applies to *any* driver that can share interrupts. This includes ahc and ahd. I just assumed that the interrupt handler could determine that the interrupt was not for it regardless of whether or not the card is generating interrupts. > 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]. This is true regardless of whether or not you have a gone flag. The interrupt handler will not be executing by the time bus_teardown_intr() returns. This is all that is required. > 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. And that thread can wakeup as soon as you release your lock. You simply cannot call bus_teardown_intr() with a lock held. Ever. > 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. I don't see that there is any problem with the above approach (it is the same flow as is used by the ahc and ahd driver) but I still don't see why a gone flag is required. Just run through the handler as you normally would in the shared interrupt case. The handler will exit if written correctly. -- Justin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1742240000.1051807110>