usb mouse dead on resume

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

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

Happens here on amd64 as well.

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.

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.

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.

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"

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

Also fails on nc8230, on first hibernate.

Fixed in newest kernel (2.6.15-22)

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.

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.

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

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.

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

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?

Cheers,
Mikko

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

--
Sincerely

Justin Sunseri

  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.

--
Sincerely

Justin Sunseri

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,
Mikko

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.

regards,
yalding

I have not seen this in edgy for a long time

So far i do not see this problem happening in feisty

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 https://wiki.ubuntu.com/KernelSuspendDebugging

Thanks all, your assistance is greatly appreciated!