Bug 5765

Summary:	complete loss of usb functionality after usb device is attched in s3 state
Product:	Drivers	Reporter:	richlv
Component:	USB	Assignee:	Alan Stern (stern)
Status:	REJECTED WILL_NOT_FIX
Severity:	normal	CC:	greg
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.15-rc6	Subsystem:
Regression:	---	Bisected commit-id:
Bug Depends on:
Bug Blocks:	5089
Attachments:	dmesg output at various moments Add debugging for when the HC dies dmesg after suspend/resume with debugging patch applied

Description richlv 2005-12-20 10:48:17 UTC

hardware environment is the same as in bug 5227

how this can be reproduced :

suspend without usb dev. attach usb mouse. resume. mouse does not work. 
replugging does not help.
suspending and resuming with mouse does not help.
suspending and resuming without mouse does not help (by replugging after 
resuming).

actually, after first resuming usb does not work at all - i tried different 
devices (blockdevices, serialconverter etc) - they are not found, even with usb 
debug enabled nothing shows up in dmesg.

attached are some dmesg outputs :
usb_loss_dmesg_startup.txt - clean boot with 2.6.15-rc6 and usb debug enabled
usb_loss_susp_res_clean.txt - suspend and resume with no device changes
usb_loss_attached_mouse_when_suspended.txt - suspended, attached usb mouse, 
resumed

Comment 1 richlv 2005-12-20 10:49:53 UTC

Created attachment 6866 [details]
dmesg output at various moments

Comment 2 Alan Stern 2005-12-21 08:22:16 UTC

Your failure log (when you plugged in the mouse during the suspend) contains this:

uhci_hcd 0000:00:11.2: host controller halted, very bad!
uhci_hcd 0000:00:11.2: HC died; cleaning up

That's not supposed to happen!  I'll send you a patch to add more debugging
information.

Comment 3 Alan Stern 2005-12-21 08:30:56 UTC

Created attachment 6870 [details]
Add debugging for when the HC dies

Comment 4 richlv 2005-12-21 09:03:56 UTC

Created attachment 6871 [details]
dmesg after suspend/resume with debugging patch applied

Comment 5 Alan Stern 2006-01-03 12:57:40 UTC

I don't get it.  Your dmesg log shows that the controller decided to stop, all
by itself, for no good reason.  The resume sequence had already finished up by
then, with no problems, and several other things had happened.

For now, I suggest you don't plug in your mouse (or anything else!) while the
computer is asleep.  But if you do and the controller dies, you should be able
to revive it by doing "rmmod uhci-hcd" followed by "modprobe uhci-hcd".

Comment 6 richlv 2006-01-03 23:19:13 UTC

seems to be another nice problem with fujitsu-siemens laptops.
as i have all drivers compiled in, i guess i will avoid plugging anything in a 
suspended computer at all.

Comment 7 Alan Stern 2006-01-04 07:48:09 UTC

You could always rebuild your kernel with uhci-hcd as a module.  But that's up
to you.

This does appear to be more Fujitsu-Siemens weirdness.  With no further clues
about the real source of the problem, there isn't anything I can do to fix it. 
(Maybe it wouldn't be fixable even if we knew the source!)

Anyway, if similar problems appear with machines from other vendors I'll have a
better chance of sorting them out.  Until then we may as well close this bug
report.  While I dislike abandoning problems in this way, I can't think of an
alternative.