From owner-freebsd-current Wed Dec 1 10:28:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 9A6C514E1C; Wed, 1 Dec 1999 10:28:19 -0800 (PST) (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 LAA13784; Wed, 1 Dec 1999 11:28:11 -0700 (MST) (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 LAA03231; Wed, 1 Dec 1999 11:28:10 -0700 (MST) Message-Id: <199912011828.LAA03231@harmony.village.org> Date: Wed, 01 Dec 1999 11:28:10 -0700 From: Warner Losh Subject: Re: PCCARD eject freeze (was Re: your mail) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ------- Blind-Carbon-Copy To: Christopher Masto Subject: Re: PCCARD eject freeze (was Re: your mail) Cc: new-bus@freebsd.org In-reply-to: Your message of "Wed, 01 Dec 1999 12:36:29 EST." <19991201123629.A5734@netmonger.net> References: <19991201123629.A5734@netmonger.net> <199912010938.BAA00461@mass.cdrom.com> <199912011605.JAA02250@harmony.village.org> Date: Wed, 01 Dec 1999 11:28:10 -0700 From: Warner Losh [[ Moved to new-bus since this starts to get into what to do on a detach ]] Problem summary for the new-bus readers: device_detach deletes the softc allocated for the device. Drivers cache copies of softc in their ISRs and other places where they sleep and count on the cached copy of softc to still be around when they are woken up. If a pccard is ejected between these points, these cached copies disappear because the ejection code deletes the device from the device tree (an as a side effect calls detach, which frees the softc for the device). Suspend has a similar problem because it can come in while a device is sleeping. In message <19991201123629.A5734@netmonger.net> Christopher Masto writes: : I think it's pretty much a given, though, that once one puts a pccard : in a laptop, one is very unlikely to be happy if one can't remove it : without powering down the machine. Particularly given that laptops : are much more useful if you can suspend them. So we need something. Agreed. Someone else will have to do the something, however, as I'm not interested in doing work that extensive on the old pccard stuff. I do not have the time if I'm going to make progress on newcard. I'm interested in talking about how to do this generically, however, since this will be one of the problems that I'll run into with newcard. : I would like to see that something along the lines of a method to shut : down the card in preparation for removal, regardless of what kind of : card it is. There is some code floating around that would allow one to do a pccardc power off slot 2 (or something to that effect, I've not used it). That would be a good generic way of coping. The problem with this, as with the others, is that the device may be in the middle doing something and needs to be clear of its critical sections/busy loops. While it usually is in the old system (and I don't think my code changes this much at all) there is always a small window for it not to be. : There are other contexts for the same issues anyway. USB has devices : that go away suddenly, and it _is_ designed to be hot-removable, so : people are going to be pulling the plug on network adapters, ZIP : drives, etc. We need drivers that are capable of going away cleanly, : or at least without a panic. Right. That's why I've said things as "devices which support detach" rather than "pccard devices". This is a generic problem, not limited to pccard. While pccard was broken for newbus, the thing that has changed is the management of the softc. In the old regime it was managed by the driver. In the new one it is managed by the newbus code. Consequently, the time of softc's removal from the system has changed from maybe never to always at detach. Hence a device can no longer count on softc being there after the detach. Since the device can go away between any instructions, this may behard to fix. Or it may just be a matter of putting the pcic device's interrupt into the tty, net, bio, cam and whatever other device classes are needed so that the usual locking mechanisms would keep softc from disappearing at interrupt context/usual critical section protection. It won't help the actual hardware going away completely while interrupts are blocked, but at least you want have softc going away in your critical section. Less that completely satisfactory. Another problem that some (all?) detachable drivers have is that they don't keep a list of sleepers on a per instance basis, so when they detach, they can't terminate the sleepers and bail out with an error to the sleeping process (which makes these sleeps uninterruptable). I'm starting to thing that we need a "rundown" or "shutdown" method that gets called before the detach to give the device a chance to shutdown gracefully before the executioner comes and removes it from the tree. However, I think this just enshrines the race w/o actually fixing it. A final option would be to allow a sleep in the detach routine. The driver would keep track of its sleepers. Detach would look like: sc->gone = 1; foreach sleeper terminate sleep while (sc->refcount) sleep(&sc->refcount); each sleeper would then do something like sc->refcount++ sleep() if (sc->gone) { sc->refcount--; wakeup (&sc->refcount); return error; } ... sc->refcount--; return; With similar code (sans sleep) in the loops in the interrupt routines. Something about it strikes me as bad, but I can't quite put my finger on what that badness is. Warner ------- End of Blind-Carbon-Copy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message