Date: Tue, 26 Oct 1999 14:07:38 -0600 From: Nate Williams <nate@mt.sri.com> To: Randell Jesup <rjesup@wgate.com> Cc: nate@mt.sri.com (Nate Williams), Terry Lambert <tlambert@primenet.com>, imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <199910262007.OAA20106@mt.sri.com> In-Reply-To: <ybug0yyku8j.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> References: <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> <ybuln8ql6gk.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> <199910261525.JAA18872@mt.sri.com> <ybug0yyku8j.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> >You're missing the point. What happens if I'm in the middle of a ISR > >when the device is popped out? How do I recognize that it's gone, when > >I'm expecting the hardware to respond to some request I've sent it? > >What happens when I'm reading a piece of memory that no longer exists? > > Ok, talking to the technical issues: > > [This assumes there's a high-priority interrupt to notify us of > card removal, and the ISR for the interrupt merely sets a flag. Note, many ISR are *NOT* interruptable (fast interrupts for one), or may be in the middle of some critical section where *all* interrupts are disabled, so notification is never given. > It also > assumes that the hardware doesn't go away before the interrupt occurs, > but may be gone by the time the processor handles the interrupt, and that > all pccard ISR's are at a lower interrupt priority than the hardware-is- > gone int.] See above. The existing FreeBSD code is coded as above (by not allowing fast interrupts on serial cards, causing performance to suck badly), but still there are problems. One, we can't use fast interrupts. Two, the drivers can still be in a critical section when the hardware is removed, and there's nothing you can do. This is the 1% case that there's nothing we can do about. (In reality, it may be .1% or even .001%, but I'll bet is closer to 1% than the rest, and it depends on the particular device driver in question.) > First, if you're reading memory that may not exist, check a > flag (whatever) after a series of associated reads, and use that to > know if the reads may have been garbage or not. No we're in the other 1% case that we can work around bug. In this 1% case, in order to do all these checks, we're effectively killing performance (10-15%) because these checks happen in the portion of the code that directly effects how effecient the driver is. > Have I missed something? Some aspect of Unix device drivers I'm > not familiar with? Nope, but this as already mentioned in the disucssion previously, and my statement was that the cost (10-15% performance hit) wasn't worth the benefit. The cost may be less, and the benefit may be greater, but since I was the one doing the coding, I deemed it an unacceptable tradeoff. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910262007.OAA20106>