Re: 2.6.25-rc7: Ugh.

[Mark Lord <lkml@rtr.ca>]

Oliver Neukum wrote:
> Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
>> Oliver Neukum wrote:
>>> 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?
> 
> hci_usb doesn't have any autosuspend code.
> 
>>>> 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?
> 
> We'll combine that information with the result of only removing usbhid
> and arrive at a pretty good idea where in the kernel the hang occurs.
> There are only two functions that touch autosuspend in the usbhid code.
> So if it works with usbhid unloaded, either of them should be to blame.
..

Thanks!

It does still hang with *usbhid* unloaded,
but not if all USB stuff is unloaded.
I'm still working my way through the rest of the suggestions here,
and USB_DEBUG=n is next.

I have figured out a way to make this much more reproducible now:
When suspended, the notebook does not supply +5V over USB.
But with a voltmeter, I discovered that there is sufficient capacitance
on the USB +5V, that it takes many minutes for the voltage to decay
from 5.1V down to near 0V.

Resuming while the voltage is still relatively high, generally works.
Resuming after the voltage drops to near zero, always fails (with USB modules loaded).

So I've put a 2Kohm resistor across the USB +5V lines,
forcing it to decay to zero within about 5 seconds.
This helps a lot for debugging here.

It probably also provides a vital clue as to what is wrong.
Resume seems to generally work when the USB devices maintain
some amount of standby power, and always fails when they don't.