Date: Wed, 27 Oct 1999 01:48:23 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rjesup@wgate.com Cc: nate@mt.sri.com, tlambert@primenet.com, imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <199910270148.SAA17060@usr02.primenet.com> In-Reply-To: <ybug0yyku8j.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> from "Randell Jesup" at Oct 26, 99 03:38:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. 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.] Invalid assumption, but fixable via virtualization to be virtually true (this is handleable via a reentrancy counter). > 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. Yes. > After sending a request to the hardware (probably by writing to > a register), check said flag, and if the hardware is gone, abort the > transaction (to the caller) with an error. Yes. > When a card is removed, wake up all pccard drivers that are in > sleeps waiting on hardware, and let them notice that the hardware is > gone and appropriately error out requests. Yes. > If you're in the middle of an ISR: Check said flag (insertion > state) at appropriate points. In many cases, you merely need check once > or twice I suspect. (I assume writes to removed cards go into the ether, > and reads return something random, which you may need to watch out for - > but often only one check before commiting the results of the interrupt.) > Even if you have to check it a fair number of times, the overhead shouldn't > be large. > > Have I missed something? Some aspect of Unix device drivers I'm > not familiar with? Nate's point about putting the checks into each driver, in particular given that these drivers are shared with less ...transigent hardware, is valid. This is adressibly on the was into the ISR by checking a bit to see if this is a hot swappable device, and eating stack state save overhead, though. The overhead doesn't occur except for the devices where it's necessary to avoid crashes. I'd like to get agreed that it's possible to work around the crappy hardware, to get a roadmap laid down, even if there isn't currently code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199910270148.SAA17060>