usb mouse dead on resume

Bug #34066 reported by Jani Monoses on 2006-03-08
Affects Status Importance Assigned to Milestone
linux-source-2.6.15 (Ubuntu)

Bug Description

On a HP nx8220 laptop there's a problem with usb and suspend.

The situation in which the mouse does ot work is resuming from hiberate _after_ a previous suspend/resume to RAM.

A suspend/resume to RAM brings the mouse back always.

Resume from hibernate leaves it in a working state only after
a reboot.

So it seems suspend to RAM does something to usb which breaks resume from disk in usb's case.
The lines
 hci_usb 2-2:1.1: no suspend for driver hci_usb?
hci_usb 2-2:1.0: no resume for driver hci_usb?
appear in dmesg before/after both types of suspend/resuming
but STR does not seem to be affected by it.

The problem is solved if I uncomment the usb modules part in /etc/acpi/

same problem but my /etc/acpi/ usb section is uncommented :-|

Mikko Saarinen (mikk0) wrote :

My usb mouse also dies when resuming from suspend. When I detach the cord and attach it again, mouse starts to work.
Haven't observed if it happens with the first suspend or only after the second one.
Sleep doesn't currently work at all, so I can't test how my mouse behaves when resumed from sleep.

I have an MSI S250 laptop with Dapper Flight 6

Martin Pitt (pitti) wrote :

Happens here on amd64 as well.

Changed in linux-source-2.6.15:
status: Unconfirmed → Confirmed
Tobias Wolf (towolf) wrote :

I experience the same as Mikko with the difference that re-attaching the mouse doesn't fix it; my mouse driver is evdev though, which generally doesn't like if the mouse moves around.

Justin Sunseri (jmsunseri) wrote :

i experience this same issue on my lenovo 3000 n100. the mouse always works when coming back from a suspend but does not work when coming back from a hibernate after the system has been suspended. Un-plugging and replugging the mouse resolves the issue.

Jani Monoses (jani) wrote :

still present with 2.6.15-21.32.
Sometimes the mouse works even after several suspend/resume cycles, but once it does not, further suspend/resumes do not seem to work either.
And it seems to depend on which usb slot it is put in (one of two on the same UHCI bus), as if changing its slot when the system is running affects
subsequent suspend/resume.

Geoff Hoff (gahoff) wrote :

On my Fujitsu P7010 I had to add the usb modules to the MODULES_WHITELIST in /etc/default/acpi-support to get usb to work correctly after resuming from hibernate. The entry on my computer looks like:

MODULES_WHITELIST="ehci_hcd uhci_hcd"

Mark Howard (mh-tildemh) wrote :

Another confirmation. In my case the mouse works most of the time after hibernate but occasionally fails (~10% of the time).

Karianne Fog Heen (simira) wrote :

Also fails on nc8230, on first hibernate.

Karianne Fog Heen (simira) wrote :

Fixed in newest kernel (2.6.15-22)

Simon Law (sfllaw) on 2006-05-03
Changed in linux-source-2.6.15:
status: Confirmed → Fix Released
Justin Sunseri (jmsunseri) wrote :

This bug has still not been resolved for me. I still have to unplug and replug my mouse after a suspend to have my USB mouse work again. If these is any information you need from me about this issue just ask.

Changed in linux-source-2.6.15:
status: Fix Released → In Progress

This is the out put from when i resume and my usb mouse is dead and i have unplugged and replugged the mouse. I hope this helps solve the problem.

Jani Monoses (jani) wrote :

problem still there with install of May the 20th daily using 2.6.15-23

Mikko Saarinen (mikk0) wrote :

Still not working and the Dapper has already been published!

This seems to be the same bug as #29834, which got fixed once, had to be reopened, got fixed again and is broken again.

WalterNicholls (walter-nic) wrote :

We get this too after upgrading breezy to dapper on a Compaq Evo 1000. Kernel version 2.6.15-23.386. A pain!

Mikko Saarinen (mikk0) wrote :

This problem can be circumvented.

Modify the /etc/default/acpi-default file and put the usb modules to the MODULES section and they are stopped on hibernate and restarted again when you resume. No need to plug the mouse out anymore =)

To find out the necessary modules run the command "lsmod | grep usb".
On my machine it prints:

usbhid 40992 0
usbcore 137700 4 ohci_hcd,ehci_hcd,usbhid

and my MODULES section from acpi-default looks like this:
# Add modules to this list to have them removed before suspend and reloaded
# on resume. An example would be MODULES="em8300 yenta_socket"
# Note that network cards and USB controllers will automatically be unloaded
# unless they're listed in MODULES_WHITELIST
MODULES="usbhid ehci_hcd ohci_hcd"

Hope that this will help others suffering from this same bug.

I read this from bug #46181. It is strange indeed that the comment above says that USB controllers will automatically be unloaded if they are not listed in MODULES_WHITELIST. Why do we still need to explicitly mention them in this list?


I should no such file /etc/default/acpi-default was one supposed to be
created already?


Justin Sunseri

Justin Sunseri (jmsunseri) wrote :

  I have no such file /etc/default/acpi-default was one supposed to be
 created already?

 I really need to proofread things before I hit enter.


Justin Sunseri

Mikko Saarinen (mikk0) wrote :

Justin wrote:

>I have no such file /etc/default/acpi-default was one supposed to be
>created already?
>I really need to proofread things before I hit enter.

Me too.

The correct filename is /etc/default/acpi-support

Sorry about that,

Yajun Wang (yalding) wrote :

I have been suffered with this problem for months. Everytime I have to use shutdown instead of hibernate.

any progress on it.

BTW: unplug and plug again does not solve the problem for me.


Jani Monoses (jani) wrote :

I have not seen this in edgy for a long time

Justin Sunseri (jmsunseri) wrote :

So far i do not see this problem happening in feisty

Peter Whittaker (pwwnow) wrote :

I'm closing this based on the latest two comments, re the bug not appearing in Edgy or Feisty. If the problem recurs, we can reopen the bug, and collect appropriate debugging information, e.g.,

The output from "uname -a", in the body of the report;

The output of "sudo lspci -vv", attached to the report (e.g., run "sudo lspci -vv> /tmp/lspci-vv and attach lspci-vv to the report - do not compress, do not include in-line);

The output of "sudo lspci -vvn", attached to the report (as above);

The output of "sudo dmidecode", attached to the report (ditto); and, if you can,

Relevant output from performing the tests on

Thanks all, your assistance is greatly appreciated!

Changed in linux-source-2.6.15:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers