From owner-freebsd-arch Mon Oct 25 9:47:14 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 5C7AD14D90 for ; Mon, 25 Oct 1999 09:47:11 -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 SAA05416 for ; Mon, 25 Oct 1999 18:47:07 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA15365 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 18:47:06 +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 008CA14D90 for ; Mon, 25 Oct 1999 09:46:55 -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 KAA04335; Mon, 25 Oct 1999 10:46:54 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA13773; Mon, 25 Oct 1999 10:46:53 -0600 Date: Mon, 25 Oct 1999 10:46:53 -0600 Message-Id: <199910251646.KAA13773@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: arch@freebsd.org Subject: Re: Racing interrupts In-Reply-To: <199910240608.AAA34462@harmony.village.org> References: <199910240608.AAA34462@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 > Consider the following situation. There is a driver talking to a > device. An unmasked interrupt happens and the device is now gone. > How does the driver know to stop what it is doing and respond to this > disappearance in a sane way? You can do what all the other OS's attempt to do, and not worry about it. On Win98/Linux, they allow the system to hang if the user ejects the card w/out properly shutting it down. So, if you do a reject on the card and something bad happens, it hangs. Yes, this isn't the best solution, but I don't believe there is a 'best' solution, or a good solution. That it happens to work some of the is good luck, not necessarily good design. In other words, I don't think a hardware solution exists. PHK and I have talked a 'bit' about this problem, and he's convinced me (in time) that it not a problem that can be solved completely. IMO, you can't sufficiently abstract it from the device, and each and every device driver requires alot of specific code that overly complicates/obfuscates the drivers in the tree. The *real* solution is to do the same kind of thing with PCCARD's that CDROM's drivers do, and not allow anyone to 'eject' the device until it's been shutdown properly, which allows the device driver to shut itself down *while* the hardware still exists. Unfortunately, this solution won't work completely due to missing hardware support. > This sort of situation comes up in the pccard code. When someone > ejects the card, an interrupt fires. If I were to remove the device > from the tree in the interrupt handler, I can invalidate the softc > that the driver is still using by freeing it. Actually, not always. You'll not always know that the device is gone when the driver is removed from the tree. It's possible (very probable) that the device may be in the process of servicing the interrupt *just* as the driver is removed, so what happens then? The code as written is trying to read from non-existing ports/memory locations, and can hang waiting for a result, or loop forever if it gets bad information. This is one of many 'races' that can not be solved w/out hardware support, since there's no way of controlling the removal of the hardware so that the software can 'clean up' safely. This is mostly independat of the softc stuff, which is BSD specific. > It is my understanding that the pccard hardware still still exist for > a period of time after the card is ejected (since it takes some period > of time to move from the pins that caused the interrupt to the > power/control/data pins being disabled). I don't know if this is > true, or if true what the period of time is. 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. :( Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message