Date: Mon, 25 Oct 1999 12:50:45 -0600 From: Warner Losh <imp@village.org> To: nate@mt.sri.com (Nate Williams) Cc: arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <199910251850.MAA42106@harmony.village.org> In-Reply-To: Your message of "Mon, 25 Oct 1999 12:27:30 MDT." <199910251827.MAA14189@mt.sri.com> References: <199910251827.MAA14189@mt.sri.com> <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
In message <199910251827.MAA14189@mt.sri.com> Nate Williams writes: : 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.) OK. So there is a small window there, but nothing that can be counted upon. One must therefore assume that the hardware is gone when the interrupt comes in... : 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. I believe it. Suspend/resume isn't too bad if you can do it from softclock and then raise SPL to a high level, detach all devices then remove power from them. Unfielded interrupts may result, but nothing worse. Card eject is a much more urgent condition in that you can't put it off for a little while to give people a chance to get out of interrupt handlers and such. : 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? Yes. W/o explicit checks for 'am I gone' it is very hard, and where do you make them, and there is still a tiny race between the checking for am I gone and the touching of hardware. These races can be made so small as to be hard to lose. That's one reason I think that having some way to terminate the current thread of execution at any instruction with a simple callback saying, "I killed your driver thread, cope with the loss of hardware" is about as good as we're going to get. I know that we don't have kernel threads, let alone driver threads so this isn't a viable option at this time, but conceptually that's what you'll have to do, I think. : When someone removes the bridge away from you while you're walking : across the chasm, how can you be expected to 'recover' from it? ;) By hanging onto the bridge :-) Or registering a SIGBRIDGE handler and hoping that the 'chute deploys in time :-). That does bring the overhead of carrying a parachute all the time on the off chance that one of the zillion bridges you walk over might cause problems. Warner 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?199910251850.MAA42106>