I realise I did something stupid, but it took a while to figure it out, and
I'm not going to be the only person to do this.
My laptop has built-in wireless (orinoco_cs), but I used a USB ethernet
adapter to plug in to the wall for a bit (ohci-hcd and pegasus).
Then I the suspended the thing, unplugged the USB adapter, and packed the
laptop up. About twelve hours later, I fire the thing up, run "dhclient" to
get a wireless connection, but the first thing it tried to touch was the USB
connection that isn't there anymore. So it hung, ctrl-c wouldn't kill it,
and the process is stuck in D state.
Trying to figure out what was going on, I ran dhclient twice more and got two
more processes stuck in D state. It took a while to remember that yesterday
I was using the USB adapter, but today I'm not.
Ordinarily, I don't think the ohci-hcd module is even loaded. The kernel
currently thinks it is, but modprobe -r ohci-hcd resulted in yet another
process in D state...
As I said, I realise that unplugging even a USB adapter with the machine is
suspended is Not A Good Thing. But it's likely to be a common thing among
people who can't figure out after the fact "oh yeah, that's what's going
wrong"...
Rob
--
http://www.linucon.org: Linux Expo and Science Fiction Convention
October 8-10, 2004 in Austin Texas. (I'm the con chair.)
Rob Landley wrote:
>
> As I said, I realise that unplugging even a USB adapter with the machine is
> suspended is Not A Good Thing. But it's likely to be a common thing among
> people who can't figure out after the fact "oh yeah, that's what's going
> wrong"...
>
Most of us that use swsusp regularly have our pre-suspend script unload usb before suspend to
prevent exactly this sort of behaviour.
I also unload PCMCIA.
If there is something using these devices that prevents unloading, then my script notifies me that
I'm doing something I need to stop before I suspend. Can't remember the last time that happened though.
Check out the swsusp-devel list for further info.
Regards,
Brad
On Sunday 27 June 2004 00:31, Brad Campbell wrote:
> Rob Landley wrote:
> > As I said, I realise that unplugging even a USB adapter with the machine
> > is suspended is Not A Good Thing. But it's likely to be a common thing
> > among people who can't figure out after the fact "oh yeah, that's what's
> > going wrong"...
>
> Most of us that use swsusp regularly have our pre-suspend script unload usb
> before suspend to prevent exactly this sort of behaviour.
> I also unload PCMCIA.
>
> If there is something using these devices that prevents unloading, then my
> script notifies me that I'm doing something I need to stop before I
> suspend. Can't remember the last time that happened though.
>
> Check out the swsusp-devel list for further info.
Yeah, I could, I just don't use USB enough. My suspend script is now stripped
down to the point where the only thing I do is run dhclient afterwards (and
that's mostly because it seems to be too stupid to notice the timeout's
elapsed. Persumably it should have some kind of trigger if the wireless
access point toggles...)
It's just that a hot-pluggable bus, it should be possible to convince the
thing to reprobe all devices on a bus reset. Oh well.
Maybe a todo item for 2.7...
Rob
--
http://www.linucon.org: Linux Expo and Science Fiction Convention
October 8-10, 2004 in Austin Texas. (I'm the con chair.)
Am Sonntag, 27. Juni 2004 10:50 schrieb Rob Landley:
> It's just that a hot-pluggable bus, it should be possible to convince the
> thing to reprobe all devices on a bus reset. ?Oh well.
No, we cannot reprobe. How are we supposed to do that?
Probe() works only on new devices. Suspend/resume cycles must
leave driver bindings alone. All we could do is fail resume().
That however is not taken notice of in the driver core.
Regards
Oliver