Date: Thu, 01 May 2003 22:01:23 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: jhb@FreeBSD.org Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h Message-ID: <20030501.220123.29064603.imp@bsdimp.com> In-Reply-To: <XFMail.20030501140515.jhb@FreeBSD.org> References: <20030501.101409.57443470.imp@bsdimp.com> <XFMail.20030501140515.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <XFMail.20030501140515.jhb@FreeBSD.org>
John Baldwin <jhb@FreeBSD.org> writes:
:
: On 01-May-2003 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.
:
: Ok, here's a question. Why is it bad for fxp_intr() to finish while
: you are blocked in bus_teardown_intr()? Put another way, perhaps
: fxp_detach() should do the teardown_intr() a lot sooner and postpone
: some of it's cleanups until after that retuns. I.e.
:
: FXP_LOCK()
: disable_interrupts_in_hardware()
: FXP_UNLOCK()
: bus_teardown_intr()
: FXP_LOCK()
: do_rest_of_detach()
The problem with fxp_intr finishing is that if the hardware is gone,
it is best to get out of the isr faster. However, as Justin points
out, this helps only a little bit.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030501.220123.29064603.imp>