Date: Thu, 01 May 2003 10:14:09 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: gibbs@scsiguy.com Cc: gallatin@cs.duke.edu Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h Message-ID: <20030501.101409.57443470.imp@bsdimp.com> In-Reply-To: <1721460000.1051803729@aslan.btc.adaptec.com> References: <XFMail.20030501101142.jhb@FreeBSD.org> <1721460000.1051803729@aslan.btc.adaptec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030501.101409.57443470.imp>