Process in D state with USB and swsuspsp
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
Signature · 2 lines
www.linucon.org: Linux Expo and Science Fiction Convention October 8-10, 2004 in Austin Texas. (I'm the con chair.)
Quoted 3 lines · Rob Landley
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
Quoted 10 lines · Brad Campbell
Quoted 4 lines · Rob Landley
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.
Quoted 5 lines
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
Signature · 2 lines
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:
Quoted 2 lines
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