From owner-freebsd-arch Mon Oct 25 11:28:52 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 73CAB14A01 for ; Mon, 25 Oct 1999 11:28:26 -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 UAA06412 for ; Mon, 25 Oct 1999 20:28:23 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA15799 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 20:28:23 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 4320E14A01 for ; Mon, 25 Oct 1999 11:27:35 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id MAA05202; Mon, 25 Oct 1999 12:27:31 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA14189; Mon, 25 Oct 1999 12:27:30 -0600 Date: Mon, 25 Oct 1999 12:27:30 -0600 Message-Id: <199910251827.MAA14189@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Warner Losh Cc: nate@mt.sri.com (Nate Williams), arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910251822.MAA41899@harmony.village.org> References: <199910251646.KAA13773@mt.sri.com> <199910240608.AAA34462@harmony.village.org> <199910251822.MAA41899@harmony.village.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : 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