Bug 150648 - USB freeze after returning from suspension/hibernation
USB freeze after returning from suspension/hibernation
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-09 04:47 EST by Bjorn Knutsson
Modified: 2015-01-04 17:17 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-04 09:21:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bjorn Knutsson 2005-03-09 04:47:42 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
Gecko/20050302 Firefox/1.0.1 Fedora/1.0.1-1.3.2

Description of problem:
After returning from suspension or hibernation, the USB system does
not reinitialize correctly, instead an error is reported repeatedly:

kernel: drivers/usb/input/hid-core.c: input irq status -84 received

The problem can be circumvented by unpluggning all USB devices before
resuming the system, and then plugging them back in again once the
system is back up. If any USB device was left plugged in at resume,
there is no way to recover.

The problem itself is known and supposedly fixed, see:

http://lkml.org/lkml/2005/1/11/138

but the bug is still present in Fedora Core 3 kernels. Presumably this
fix will get into Fedora Core 3 once 2.6.11 is adopted, but I thought
I'd enter this bug explicitly, in case 2.6.11 is held back for FC3.



Version-Release number of selected component (if applicable):
kernel-2.6.10-1.770_FC3

How reproducible:
Always

Steps to Reproduce:
1. Plug in a USB device, e.g., USB mouse
2. Suspend system (I've only tried using APM suspend and hibernate)
3. Resume system with USB device still plugged in.
4. Note that device no longer works.
5. Check dmesg, console or /var/log/messages for "looping" error message.


Actual Results:  USB device no longer works, unplugging/replugging
will not help. Tons of error messages generated.


Expected Results:  USB device should work as before suspension.

Additional info:

Mar  7 07:44:15 foo kernel: drivers/usb/input/hid-core.c: input irq
status -84 received
Mar  7 07:44:46 foo last message repeated 1268 times
Mar  7 07:45:47 foo last message repeated 2541 times
Mar  7 07:46:48 foo last message repeated 2542 times
Mar  7 07:47:49 foo last message repeated 2541 times
Mar  7 07:48:50 foo last message repeated 2541 times
Mar  7 07:49:51 foo last message repeated 2541 times
Mar  7 07:50:52 foo last message repeated 2542 times
Mar  7 07:51:53 foo last message repeated 2537 times
Mar  7 07:52:54 foo last message repeated 2540 times
Mar  7 07:53:55 foo last message repeated 2541 times
Mar  7 07:54:56 foo last message repeated 2542 times
Mar  7 07:55:57 foo last message repeated 2541 times
Mar  7 07:56:58 foo last message repeated 2542 times
Mar  7 07:57:59 foo last message repeated 2541 times
Mar  7 07:59:00 foo last message repeated 2542 times
Mar  7 08:00:01 foo last message repeated 2541 times
Mar  7 08:00:08 foo last message repeated 303 times
Comment 1 Warren Togami 2005-03-23 00:01:24 EST
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?
Comment 2 Bjorn Knutsson 2005-03-23 07:12:35 EST
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.
Comment 3 Bjorn Knutsson 2005-03-24 06:59:47 EST
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.
Comment 4 Dave Jones 2005-07-15 14:20:22 EDT
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.
Comment 5 Bjorn Knutsson 2005-08-02 06:30:14 EDT
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.
Comment 6 Bjorn Knutsson 2005-08-02 06:55:55 EDT
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.
Comment 7 Dave Jones 2006-01-16 17:35:21 EST
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.
Comment 8 Len Brown 2006-01-18 02:00:35 EST
Do all the notes above refer to using APM to suspend?
If yes, exactly how is suspend invoked?

Does ACPI suspend behave differently?
Comment 9 Dave Jones 2006-02-03 00:36:59 EST
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.
Comment 10 John Thacker 2006-05-04 09:21:36 EDT
Closing per previous comment.

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