Date: Mon, 25 Oct 1999 12:27:30 -0600 From: Nate Williams <nate@mt.sri.com> To: Warner Losh <imp@village.org> Cc: nate@mt.sri.com (Nate Williams), arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <199910251827.MAA14189@mt.sri.com> In-Reply-To: <199910251822.MAA41899@harmony.village.org> References: <199910251646.KAA13773@mt.sri.com> <199910240608.AAA34462@harmony.village.org> <199910251822.MAA41899@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> : Not true at all. Otherwise, the 'hardware' would have to emulate the > : functionality of every card that was once in the slot, and respond in > : the same fashion. :( > > OK. Somehow I had it in my head that pccard slots had pins of > differing lenght and the short ones were used to trigger interrupts a > fraction of a second before the card itself went dead due to the > address/data pins going away. Possibly, but the races still exist, and you can still get in a position where the hardware is gone. (I've verified this, having done alot of the work in the old pccard on suspend/resume.) > This is one reason that I want each driver in its own thread and that > the interrupt that says the card is gone to effectively do a longjump > to a "You are now gone, don't touch hardware, but cleanup the best you > can" routine. However, I'm not sure what this would do to driver > complexity. According to Sean Fagan, Stratus did in fact go to these kinds of lengths to make suspend/resume*insert/eject work, but it required re-writing/re-coding all of the drivers to support. It's certainly not impossible, but it does make the drivers that much more complex. And, (not to disagree with Sean), I don't see how you fix all the problems, simply because at some point you must assume the hardware exists, and if it disappears in the middle of an operation without any way of knowing that it's gone, how can you recover from it? When someone removes the bridge away from you while you're walking across the chasm, how can you be expected to 'recover' from it? ;) 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?199910251827.MAA14189>