Bug 1165206 - USB mouse fails after resume from suspend
Summary: USB mouse fails after resume from suspend
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Josh Boyer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-11-18 14:53 UTC by Fred Wells
Modified: 2014-12-13 09:52 UTC (History)
8 users (show)

Fixed In Version: kernel-3.17.6-200.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-13 09:52:37 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Requested USB files. (18.31 KB, application/zip)
2014-11-19 14:32 UTC, Fred Wells
no flags Details
[PATCH] usb-quirks: Add reset-resume quirk for MS Wireless Laser Mouse 6000 (1.08 KB, patch)
2014-11-20 14:20 UTC, Hans de Goede
no flags Details | Diff
lspci, lsusb and dmesg output (19.95 KB, application/zip)
2014-11-20 23:31 UTC, Fred Wells
no flags Details
working and non-working outputs (20.30 KB, application/zip)
2014-11-21 00:10 UTC, Fred Wells
no flags Details
latest outputs (20.29 KB, application/zip)
2014-11-21 14:58 UTC, Fred Wells
no flags Details

Description Fred Wells 2014-11-18 14:53:29 UTC
Description of problem:

After resume from suspend, usb mouse is completely unresponsive.

Version-Release number of selected component (if applicable):

kernel 3.17.2-200.fc20.x86_64
xorg-x11-server-Xorg.x86_64 1.14.4-11.fc20

How reproducible:

Every time.

Steps to Reproduce:
1.  Suspend to RAM
2.  Resume from suspend

Actual results:

Mouse is totally unresponsive.  Other USB devices (eg storage) are working fine.

Expected results:

Mouse should be functional.

Additional info:

Comment 1 Hans de Goede 2014-11-18 14:57:59 UTC
Hi,

Can you please before suspend (so with a working mouse), do:

lsusb > lsusb.before

Then suspend & resume, and do:

lsusb > lsusb.after
dmesg > dmesg.txt

And then attach the 3 generated text files here ?

Thanks,

Hans

Comment 2 Fred Wells 2014-11-19 14:32:42 UTC
Created attachment 958983 [details]
Requested USB files.

Requested USB files.

Comment 3 Hans de Goede 2014-11-20 14:19:46 UTC
Hi Fred,

So it looks like the USB receiver for your mouse does not come back after a suspend/resume (it is gone from lsusb). The only thing I can think of which might help is adding a reset-resume quirk. Unfortunately there is no mechanism to add this on the fly, so to test you need to build a new kernel.

I'll attach a patch here for this. Let me know if you've no experience in building kernels, then I'll do a scratch build for you with the patch added, and give you rpms to test.

Regards,

Hans

Comment 4 Hans de Goede 2014-11-20 14:20:52 UTC
Created attachment 959381 [details]
[PATCH] usb-quirks: Add reset-resume quirk for MS Wireless Laser Mouse 6000

This patch may fix this, please give it a try.

p.s.

In the mean time unplugging and replugging the receiver should work as a work-around.

Comment 5 Fred Wells 2014-11-20 14:46:13 UTC
Couple more notes...

- Works fine after suspend to disk, only fails after suspend to RAM.
- Replugging the receiver does not work.
- This worked perfectly until the release of kernel 3.10, which broke suspend to RAM altogether (https://bugzilla.redhat.com/show_bug.cgi?id=1005020 - only recently fixed with kernel 3.17.2-200.fc20.x86_64)

Comment 6 Hans de Goede 2014-11-20 15:59:18 UTC
(In reply to Fred Wells from comment #5)
> Couple more notes...
> 
> - Works fine after suspend to disk, only fails after suspend to RAM.
> - Replugging the receiver does not work.
> - This worked perfectly until the release of kernel 3.10, which broke
> suspend to RAM altogether
> (https://bugzilla.redhat.com/show_bug.cgi?id=1005020 - only recently fixed
> with kernel 3.17.2-200.fc20.x86_64)

Hmm, if replugging does not help then likely the problem is elsewhere, and my reset on resume patch is not going to help.

I suspect that the usb-port is no longer getting any power, you said that " Other USB devices (eg storage) are working fine." what happens if you put the mouse receiver in the port where the usb storage device keeps working fine ?  And while at it what happens to an usb-storage device if plugged into the mouse port ?

Also can you provide the output of "lspci -nn" please ?

Comment 7 Fred Wells 2014-11-20 23:31:08 UTC
Created attachment 959508 [details]
lspci, lsusb and dmesg output

Requested lspci output attached.

Rearranging the USB devices makes no difference whatsoever, as you can see from the new attachment.  This, however, seems interesting from dmesg...

  [  269.828091] PM: Finishing wakeup.
  [  269.828096] Restarting tasks ... 
  [  269.828297] usb 3-1: USB disconnect, device number 2
  [  269.837014] done.

The device being disconnected appears to be the USB mouse, from lsusb...

  Bus 003 Device 002: ID 045e:00e1 Microsoft Corp. Wireless Laser Mouse 6000 Reciever

Comment 8 Fred Wells 2014-11-21 00:10:22 UTC
Created attachment 959510 [details]
working and non-working outputs

Interestingly, another model MS USB mouse works fine.

Working ...

  Bus 005 Device 002: ID 045e:0745 Microsoft Corp. Nano Transceiver v1.0 for Bluetooth

Failing ...

   Bus 003 Device 002: ID 045e:00e1 Microsoft Corp. Wireless Laser Mouse 6000 Reciever

Comment 9 Hans de Goede 2014-11-21 12:13:11 UTC
Hi,

Can you try unplugging the (problem) mouse from the port it is in after a suspend/resume and then
plug it into another port ?  And can you also try inserting another device in the port the mouse was in after suspend/resume and see if that works ?

Regards,

Hans

Comment 10 Hans de Goede 2014-11-21 12:51:26 UTC
Hi again,

While at it I've also started a scratch kernel build with the reset-resume patch, lets give it a try, who knows maybe it helps ?

Please download kernel-3.17.3-...rpm for your arch from here:
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=8201334
(note this is still building atm)

And install it with:

rpm -ivh kernel-3.17.3-...rpm

Then reboot into the new kernel and see if it fixes the suspend / resume problem.

Regards,

Hans

Comment 11 Fred Wells 2014-11-21 14:58:56 UTC
Created attachment 959787 [details]
latest outputs

The new kernel fixes the issue. 

To answer your earlier question, it fails with the old kernel regardless of where I plug the mouse in either before or after resume.

Comment 12 Hans de Goede 2014-11-21 15:59:33 UTC
(In reply to Fred Wells from comment #11)
> Created attachment 959787 [details]
> latest outputs
> 
> The new kernel fixes the issue. 

That is good news, are you 100% sure on this (I'm a bit surprised since an unplug / replug does not help).

Surprised but happy, if you can double check I'll send the patch fixing this upstream.

Comment 13 Fred Wells 2014-11-21 23:18:18 UTC
I even tried with the vanilla 3.17.3-200.fc20.x86_64 from the repo to be sure it wasn't already fixed there.   Alas, it only works with your patched version.  Of that I am 100% sure.  I'm also 100% sure the unplug/replug does not work.

Comment 14 Hans de Goede 2014-11-24 10:24:39 UTC
Hi Fred,

Ok, thanks for the input, I've send the patch fixing this upstream.

Josh, can you add the patch attached to this bug-report to the Fedora kernels, to fix this until it trickles down through upstream ?

Thanks & Regards,

Hans

Comment 15 Josh Boyer 2014-11-24 14:49:19 UTC
(In reply to Hans de Goede from comment #14)
> Hi Fred,
> 
> Ok, thanks for the input, I've send the patch fixing this upstream.
> 
> Josh, can you add the patch attached to this bug-report to the Fedora
> kernels, to fix this until it trickles down through upstream ?

Added, thanks.

Comment 16 Fedora Update System 2014-12-08 21:52:55 UTC
kernel-3.17.6-200.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/kernel-3.17.6-200.fc20

Comment 17 Fedora Update System 2014-12-12 04:16:56 UTC
Package kernel-3.17.6-200.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.17.6-200.fc20'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-16632/kernel-3.17.6-200.fc20
then log in and leave karma (feedback).

Comment 18 Fedora Update System 2014-12-13 09:52:37 UTC
kernel-3.17.6-200.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.


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