Date: Mon, 25 Oct 1999 10:46:53 -0600 From: Nate Williams <nate@mt.sri.com> To: Warner Losh <imp@village.org> Cc: arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <199910251646.KAA13773@mt.sri.com> In-Reply-To: <199910240608.AAA34462@harmony.village.org> References: <199910240608.AAA34462@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910251646.KAA13773>