Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
quoted text
> 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.

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?

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.

	Regards
		Oliver


--
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/