Bug 5765 - complete loss of usb functionality after usb device is attched in s3 state
Summary: complete loss of usb functionality after usb device is attched in s3 state
Status: REJECTED WILL_NOT_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: USB (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Alan Stern
URL:
Keywords:
Depends on:
Blocks: USB
  Show dependency tree
 
Reported: 2005-12-20 10:48 UTC by richlv
Modified: 2006-01-04 07:48 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.15-rc6
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
dmesg output at various moments (6.26 KB, application/bzip2)
2005-12-20 10:49 UTC, richlv
Details
Add debugging for when the HC dies (2.04 KB, patch)
2005-12-21 08:30 UTC, Alan Stern
Details | Diff
dmesg after suspend/resume with debugging patch applied (6.30 KB, text/plain)
2005-12-21 09:03 UTC, richlv
Details

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.

Note You need to log in before you can comment on or make changes to this bug.