Oliver Neukum wrote:
quoted text
> Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
>
>> One thing I just tried, was to unload all USB stuff before suspend,
>> and reload on resume -- just stuck the commands into my suspend/resume script.
>>
>> The machine has been 100% rock solid since then.
>> So I think that definitely implicates USB.
> 
> Yes. What happens if you unload only usbhid at that time?
..

Mmm.. interesting choice, there.  I'll try that.

There is another quirk on this machine that might confuse
software that's not robust:  the internal Bluetooth adapter
is USB connected, and I normally have it disabled (BIOS hotkey).
So it normally is "not present".

But on any power-on / resume, it briefly powers up and becomes "present",
and, after a second or two, the BIOS powers it down again, "not present".

Just long enough for software to notice it and try talking to it.
If that software is not carefully coded, it might get confused.

This has not been a problem before, but perhaps with the new USB autosuspend code?

quoted text
>> Still want USB_SUSPEND=n ?  Please explain.
> 
> It looks like you are hanging in the kthread for autosuspending.
> Compiling that out should confirm it.
..

Okay, and once we see that it works fine:  then what?
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/