|Summary:||complete loss of usb functionality after usb device is attched in s3 state|
|Component:||USB||Assignee:||Alan Stern (stern)|
|Bug Depends on:|
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.