Bug 1165206

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

Created attachment 958983 [details]
Requested USB files.

Requested USB files.

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

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.

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)

(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 ?

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

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

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

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

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.

(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.

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.

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

(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.

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

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).

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.