Date: Thu, 01 May 2003 09:42:09 -0600 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: John Baldwin <jhb@freebsd.org> Cc: Andrew Gallatin <gallatin@cs.duke.edu> Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h Message-ID: <1721460000.1051803729@aslan.btc.adaptec.com> In-Reply-To: <XFMail.20030501101142.jhb@FreeBSD.org> References: <XFMail.20030501101142.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Yes, bus_teardown_intr() does block and people were complaining that it does. It seems to be the only way to do this cleanly unless you start playing with alternate interrupt stubs that happen to reside outside the module you are loading, etc. > The only problem that needs to be worked around (which you probably already > do) is to make sure that if the handler is currently blocked on the lock > when you do the teardown, it will not hose anything (like turn interrupts > back on) when it executes. For fxp(4), Warner used a 'gone' flag to make it > so that fxp_intr() returned immediately in that case. The fxp interrupt handler (at least in stable) doesn't re-enable interrupts. So, the above strategy should work for fxp too. >> 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. -- Justin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1721460000.1051803729>