Bug 150648
| Summary: | USB freeze after returning from suspension/hibernation | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Bjorn Knutsson <bjorn4+bugzilla> |
| Component: | kernel | Assignee: | Dave Jones <davej> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4 | CC: | acpi-bugzilla, pfrields, wtogami |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-05-04 13:21:36 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Bjorn Knutsson
2005-03-09 09:47:42 UTC
http://people.redhat.com/davej/kernels/Fedora/FC3/ Please try the 2.6.11 candidate kernel for FC3 from here after installing all FC3 updates. Does it work properly? I've installed the 2.6.11 candidate (2.6.11-1.7_FC3 for i686), and while it supresses the looping error message, USB does not work when the system is resumed. The messages relating to USB in the log after suspension are: Mar 23 12:53:40 foo kernel: hub 2-0:1.0: resubmit --> -108 Mar 23 12:53:40 foo kernel: hub 2-0:1.0: hub_port_status failed (err = -11) As before, if I unplug the USB device (e.g., a mouse) before resuming the system, I can later plug it in and have it work correctly. However, once you have resumed with the USB device in, you can't suspend, unplug, resume, plug in and have it back to working again. Pre-2.6.11 reports indicated that the problem could be worked around if the whole USB subsystem is built as modules and unloaded before suspension and then re-loaded after resume. In this case, things work as intended. The FC3 kernel is, however, not built with USB as modules, so I have not been able to verify this. Side note: While the 2.6.11 candidate doesn't fix the USB bug, it *does* fix another annoying suspend/resume-related problem, namely time warp. Previously, after suspending, the time would warp into the future roughly proportional to the length of the suspension. While the resume-scripts would reset the clock soon after the system was resumes, this meant that any program that was sleeping would keep sleeping until the actual time had caught up with the time warp. With the 2.6.11 candidate, this does not seem to happen any more. An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you. I have installed the update now, and done some testing. I tried first to suspend the system to ram (using APM suspend), and when the system came back on, things seemed to work (could use my mouse). I then tried suspend to disk (APM hibernate), and when the system came back on, the mouse no longer worked. I tried unplugging and replugging it, to no avail. Checking messages, I noticed that from the first cycle, I got the following messages relating to USB: Aug 2 12:11:39 phobos apmd[2986]: System Suspend Aug 2 12:12:16 phobos kernel: hub 2-0:1.0: resubmit --> -108 Aug 2 12:12:18 phobos kernel: usb 2-2: USB disconnect, address 2 Aug 2 12:12:18 phobos kernel: usb 2-2: new low speed USB device using uhci_hcd and address 3 Aug 2 12:12:18 phobos kernel: input: USB HID v1.10 Mouse [Logitech USB-PS/2 Opt ical Mouse] on usb-0000:00:1d.1-2 Aug 2 12:12:19 phobos apmd[2986]: Normal Resume after 00:00:40 (100% unknown) A C power On subsequent suspend/resume cycles, there were no messages relating to USB. I will reboot my machine and try again, this time with repeated suspend to ram. For now, it seems that the update does not resolve the problem. I have now done some additional experiments. First of all, it does not matter what type of suspension is used. It will correctly reinitialize the USB after the first suspension, but not after the second. Second, as before, I can do any number of suspend/resume cycles if I unplug the USB device before suspending, and replug it again after the resume. A little more experimentation has, however, revealed something I think may be a clue. I tried to suspend/resume with the USB device plugged in. The system came back, and the USB device worked as in the previous experiments. This time, however, I wanted to try unplugging the device before doing the second suspend/resume. Watching the messages, I noticed that the system did not seem to notice that I unplugged the device. Before doing a suspend/resume with the device plugged in, I would get a message saying: Aug 2 12:41:23 phobos kernel: usb 2-2: USB disconnect, address 3 when I unplugged the device. After a suspend/resume cycle in which the USB device was plugged in (and worked, since it was the first cycle since reboot), there was no such message. Nor one when a USB device is plugged in. It thus seems like while the USB resume code now correctly can suspend and resume once, something gets messed up in this process that causes the USB system to be unable to detect USB connects/disconnects after resuming. The problem only occurs if a USB device was plugged in during suspend/resume, i.e., it is likely in the code handling suspend/resume of plugged in devices, since the problem does not occur if no device is plugged in during suspend/resume. This is a mass-update to all currently open Fedora Core 3 kernel bugs. Fedora Core 3 support has transitioned to the Fedora Legacy project. Due to the limited resources of this project, typically only updates for new security issues are released. As this bug isn't security related, it has been migrated to a Fedora Core 4 bug. Please upgrade to this newer release, and test if this bug is still present there. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. Thank you. Do all the notes above refer to using APM to suspend? If yes, exactly how is suspend invoked? Does ACPI suspend behave differently? This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you. Closing per previous comment. |