Date: Wed, 01 Dec 1999 11:28:10 -0700 From: Warner Losh <imp@village.org> Subject: Re: PCCARD eject freeze (was Re: your mail) Message-ID: <199912011828.LAA03231@harmony.village.org>
next in thread | raw e-mail | index | archive | help
------- Blind-Carbon-Copy
To: Christopher Masto <chris@netmonger.net>
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 <imp@harmony.village.org>
[[ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912011828.LAA03231>