From owner-freebsd-arch Mon Oct 25 11:51:21 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3C39F14CAF for ; Mon, 25 Oct 1999 11:51:10 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA06667 for ; Mon, 25 Oct 1999 20:51:07 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA15965 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 20:51:07 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 0EE2B15203 for ; Mon, 25 Oct 1999 11:50:01 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA31393; Mon, 25 Oct 1999 12:49:59 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA42106; Mon, 25 Oct 1999 12:50:45 -0600 (MDT) Message-Id: <199910251850.MAA42106@harmony.village.org> To: nate@mt.sri.com (Nate Williams) Subject: Re: Racing interrupts Cc: arch@freebsd.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> Date: Mon, 25 Oct 1999 12:50:45 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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