Bug 989138 - Logitech Wireless Mouse Mouse Broken After kernel-3.10.3-300.fc19.x86_64
Logitech Wireless Mouse Mouse Broken After kernel-3.10.3-300.fc19.x86_64
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
Unspecified Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Reopened
: 989229 994227 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-27 16:48 EDT by Garry T. Williams
Modified: 2013-08-09 13:12 EDT (History)
15 users (show)

See Also:
Fixed In Version: kernel-3.10.5-201.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-09 13:12:04 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
wireshark screenshot (150.49 KB, image/png)
2013-07-31 14:26 EDT, Mikhail
no flags Details
wireshark capture (25.06 KB, application/octet-stream)
2013-07-31 21:44 EDT, Garry T. Williams
no flags Details
wireshark capture for kernel 3.10.4-300.fc19.x86_64 (130.28 KB, application/octet-stream)
2013-07-31 22:08 EDT, Theodore Lee
no flags Details
wireshark capture for kernel 3.9.9-302.fc19.x86_64 (156.28 KB, application/octet-stream)
2013-07-31 22:09 EDT, Theodore Lee
no flags Details
my capture of pluging mouse (105.33 KB, application/octet-stream)
2013-08-02 15:26 EDT, Mikhail
no flags Details

  None (edit)
Description Garry T. Williams 2013-07-27 16:48:34 EDT
Description of problem: Mouse doesn't work


Version-Release number of selected component (if applicable): kernel-3.10.3-300.fc19.x86_64


How reproducible: Always


Steps to Reproduce:
1. Boot new kernel
2.
3.

Actual results: Unresponsive mouse


Expected results: Mouse works


Additional info: works in kernel-3.9.9-302.fc19.x86_64

kernel: usb 3-1: new full-speed USB device number 4 using xhci_hcd
kernel: usb 3-1: New USB device found, idVendor=046d, idProduct=c52b
kernel: usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
kernel: usb 3-1: Product: USB Receiver
kernel: usb 3-1: Manufacturer: Logitech
kernel: logitech-djreceiver 0003:046D:C52B.0009: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-1/input2
mtp-probe[1682]: checking bus 3, device 4: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1"
mtp-probe[1682]: bus: 3, device: 4 was not an MTP device
Comment 1 Garry T. Williams 2013-07-28 10:40:52 EDT
One more data point:

On another system, the same kernel has no problem with a similar Logitech device:

kernel: usb 4-1: New USB device found, idVendor=046d, idProduct=c52b
kernel: usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
kernel: usb 4-1: Product: USB Receiver
kernel: usb 4-1: Manufacturer: Logitech
kernel: logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:1a.1-1/input2
kernel: input: Logitech Unifying Device. Wireless PID:1025 as /devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.2/0003:046D:C52B.0003/input/input2
kernel: logitech-djdevice 0003:046D:C52B.0004: input,hidraw1: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless PID:1025] on usb-0000:00:1a.1-1:1

This system is a Dell desktop and the failing system is a Dell XPS13 laptop.

Working system (desktop):

$ lsusb
Bus 001 Device 003: ID 152d:2329 JMicron Technology Corp. / JMicron USA Technology Corp. JM20329 SATA Bridge
Bus 004 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 006 Device 002: ID 413c:2003 Dell Computer Corp. Keyboard
Bus 007 Device 002: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
$

Failing system (laptop):

$ lsusb
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 1bcf:288f Sunplus Innovation Technology Inc. 
Bus 002 Device 003: ID 8087:07da Intel Corp. 
$

I tried physically swapping the devices and the laptop system continues to fail and the desktop system works fine.
Comment 2 Theodore Lee 2013-07-29 06:06:07 EDT
I'm having the same problem on an Asus N56VZ with a Logitech m905 Anywhere MX mouse and unifying receiver.

dmesg:
[  200.291738] usb 3-3: new full-speed USB device number 5 using xhci_hcd
[  200.305443] usb 3-3: New USB device found, idVendor=046d, idProduct=c52b
[  200.305450] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  200.305464] usb 3-3: Product: USB Receiver
[  200.305465] usb 3-3: Manufacturer: Logitech
[  200.310684] logitech-djreceiver 0003:046D:C52B.000A: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-3/input2

lsusb entry:
Bus 003 Device 005: ID 046d:c52b Logitech, Inc. Unifying Receiver

This looks like it's probably https://bugzilla.kernel.org/show_bug.cgi?id=60507

Is there any chance the kernel package could carry a patch for this until this bug gets attention upstream? The Asus N56 has a fairly terrible touchpad. =(
Comment 3 Josh Boyer 2013-07-29 08:45:42 EDT
Benjamin, any thoughts on this one?
Comment 4 Benjamin Tissoires 2013-07-29 09:11:16 EDT
There are already few upstream discussions about this bug. I thought it was related to the 3.11-rc series, but actually, this land into 3.10.

So, the current consensus is to revert commit 8af6c08830b1ae114d1a8b548b1f8b056e068887 (Revert "HID: Fix logitech-dj: missing Unifying device issue"), which triggers the bug until we find out the true USB3 problem.

It should be fixed in this branch (just 2 commits from Nestor):
http://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/log/?h=for-3.11/logitech-enumeration-fix

I'm not sure when this will land in Linus' tree or in stable tree, but definitively, we can revert the revert in Fedora.
Comment 5 Benjamin Tissoires 2013-07-29 11:00:51 EDT
*** Bug 989229 has been marked as a duplicate of this bug. ***
Comment 6 Josh Boyer 2013-07-30 06:45:16 EDT
OK, I've added those two patches.  Thanks Benjamin!
Comment 7 Fedora Update System 2013-07-30 10:07:56 EDT
kernel-3.10.4-300.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/kernel-3.10.4-300.fc19
Comment 8 Garry T. Williams 2013-07-30 21:28:39 EDT
I installed https://admin.fedoraproject.org/updates/kernel-3.10.4-300.fc19 but it doesn't fix the mouse.

garry@tfr$ rpm -qa|grep kernel|grep 4-300
kernel-modules-extra-3.10.4-300.fc19.x86_64
kernel-headers-3.10.4-300.fc19.x86_64
kernel-3.10.4-300.fc19.x86_64
kernel-devel-3.10.4-300.fc19.x86_64
garry@tfr$

Any other information I can provide?
Comment 9 Theodore Lee 2013-07-30 21:55:56 EDT
Hmm... I'm not seeing any improvement from 3.10.4-300 either. =( No change in log output as far as I can tell.
Comment 10 Benjamin Tissoires 2013-07-31 08:19:35 EDT
hmm... this is strange. I would need then the usbmon traces.
Please run wireshark (as root :( ), then start a capture for the usbmon devices. Plug your receiver, wait few seconds, and then move your mouse.
Stop the capture, and attach the results to the bug.
Comment 11 Mikhail 2013-07-31 14:25:33 EDT
Which of usbmons I needed to capture?
Comment 12 Mikhail 2013-07-31 14:26:19 EDT
Created attachment 781296 [details]
wireshark screenshot
Comment 13 Garry T. Williams 2013-07-31 21:44:12 EDT
Created attachment 781399 [details]
wireshark capture

I'm attaching a trace from wireshark.
Comment 14 Theodore Lee 2013-07-31 22:03:17 EDT
(In reply to Mikhail from comment #11)
> Which of usbmons I needed to capture?

I'm not that familiar with wireshark, so there's probably a better way to do this, but you can use lsusb to figure out which bus your device's USB port is on (while it's plugged in, of course), and later on capture the usbmon device corresponding to that bus.
Comment 15 Theodore Lee 2013-07-31 22:08:06 EDT
Created attachment 781403 [details]
wireshark capture for kernel 3.10.4-300.fc19.x86_64

Attaching additional wireshark captures in case they're useful. This is for the non-working but patched kernel 3.10.4-300.fc19.x86_64

I'll attach another capture for the working kernel 3.9.9-302.fc19.x86_64 - unfortunately I don't have the unpatched kernel 3.10.3-300.fc19.x86_64 on hand, but I suppose I could install it if a trace from that would be useful.
Comment 16 Theodore Lee 2013-07-31 22:09:23 EDT
Created attachment 781404 [details]
wireshark capture for kernel 3.9.9-302.fc19.x86_64
Comment 17 Benjamin Tissoires 2013-08-01 03:56:14 EDT
thanks for the traces. I got all I need.

Josh can you remove the second patch sent by Nestor (HID-hid-logitech-dj-querying_devices-was-never-set.patch)? It does break the enumeration. With only the revert, we will be at the same state than we were on the 3.9 series.
Comment 18 Josh Boyer 2013-08-01 08:23:08 EDT
Dropped.  Should be in the next build.  Thanks for working through this everyone.
Comment 19 Theodore Lee 2013-08-01 20:27:00 EDT
Thank you for the prompt response. =)

I see a kernel 3.10 build for Fedora 18 which doesn't seem to be carrying the revert patch. Will the patch be needed there as well?
Comment 20 Fedora Update System 2013-08-01 23:32:09 EDT
kernel-3.10.4-300.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 21 Theodore Lee 2013-08-01 23:36:27 EDT
Reopening as this isn't quite fixed yet.
Comment 22 Mikhail 2013-08-02 15:25:40 EDT
Please see also my capture. May be not same problem, because when I plug mouse directly it works, not work's when I plug mouse via USB hub. Also not worked USB flash when I plug via USB hub.
Comment 23 Mikhail 2013-08-02 15:26:33 EDT
Created attachment 782144 [details]
my capture of pluging mouse
Comment 24 Benjamin Tissoires 2013-08-03 06:14:39 EDT
(In reply to Mikhail from comment #22)
> Please see also my capture. May be not same problem, because when I plug
> mouse directly it works, not work's when I plug mouse via USB hub. Also not
> worked USB flash when I plug via USB hub.

Well, this is the exact same problem. hid-logitech-dj reveal a bug in the USB subsystem, and the current fix is a total workaround. So the fix should work for you too (for the mouse part, not the flash one).
Comment 25 Zach Carter 2013-08-05 18:46:48 EDT
Additional data point.  I did a local build of the git master (rawhide) 3.11.0 rc4 branch, kernel-3.11.0-0.rc4.git0.1.fc20.x86_64, and it has the same problem.
Comment 26 mock 2013-08-06 08:53:40 EDT
i am having the same situation with my logitech m600 wireless mouse not connecting. but the odd thing is this: if i start up a vm running windows 8 (yeah, i know), the mouse works in the windows vm. if i then run the logitech unifying software to sync the mouse with the usb transmitter, and then shut down the vm, the mouse works in fedora 19.

for what it's worth...

dmesg snip after plugging in my connector before running the vm:

[ 1972.830927] usb 3-2: new full-speed USB device number 6 using xhci_hcd
[ 1972.844731] usb 3-2: New USB device found, idVendor=046d, idProduct=c52b
[ 1972.844742] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1972.844748] usb 3-2: Product: USB Receiver
[ 1972.844753] usb 3-2: Manufacturer: Logitech
[ 1972.850341] logitech-djreceiver 0003:046D:C52B.000F: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-2/input2

and here is everything after that last line having started and stopped my win 8 vm:

[ 2126.970573] cgroup: libvirtd (1306) created nested cgroup for controller "memory" which has incomplete hierarchy support. Nested cgroups may change behavior in the future.
[ 2126.970576] cgroup: "memory" requires setting use_hierarchy to 1 on the root.
[ 2126.970736] cgroup: libvirtd (1306) created nested cgroup for controller "blkio" which has incomplete hierarchy support. Nested cgroups may change behavior in the future.
[ 2127.005740] device vnet0 entered promiscuous mode
[ 2127.010948] virbr0: topology change detected, propagating
[ 2127.010952] virbr0: port 2(vnet0) entered forwarding state
[ 2127.010966] virbr0: port 2(vnet0) entered forwarding state
[ 2136.997228] virbr0: port 2(vnet0) entered disabled state
[ 2136.997641] device vnet0 left promiscuous mode
[ 2136.997650] virbr0: port 2(vnet0) entered disabled state
[ 2148.762725] device vnet0 entered promiscuous mode
[ 2148.776951] virbr0: topology change detected, propagating
[ 2148.776957] virbr0: port 2(vnet0) entered forwarding state
[ 2148.776970] virbr0: port 2(vnet0) entered forwarding state
[ 2149.499801] usb 3-2: reset full-speed USB device number 6 using xhci_hcd
[ 2149.511831] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b96c0
[ 2149.511836] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b90c0
[ 2149.511839] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b9440
[ 2149.570606] usb 3-2: usbfs: interface 0 claimed by usbhid while 'qemu-system-x86' sets config #1
[ 2161.851089] usb 3-2: reset full-speed USB device number 6 using xhci_hcd
[ 2161.863144] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b96c0
[ 2161.863149] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b90c0
[ 2161.863160] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b9440
[ 2161.865431] logitech-djreceiver 0003:046D:C52B.0010: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-2/input2
[ 2161.870132] input: Logitech Unifying Device. Wireless PID:401a as /devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2:1.2/0003:046D:C52B.0010/input/input11
[ 2161.870272] logitech-djdevice 0003:046D:C52B.0013: input,hidraw1: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless PID:401a] on usb-0000:00:14.0-2:1
[ 2162.046183] usb 3-2: reset full-speed USB device number 6 using xhci_hcd
[ 2162.058285] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b96c0
[ 2162.058288] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b90c0
[ 2162.058290] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b9440
[ 2162.154589] usb 3-2: usbfs: interface 0 claimed by usbhid while 'qemu-system-x86' sets config #1
[ 2291.426237] virbr0: port 2(vnet0) entered disabled state
[ 2291.426294] device vnet0 left promiscuous mode
[ 2291.426302] virbr0: port 2(vnet0) entered disabled state
[ 2291.586536] usb 3-2: reset full-speed USB device number 6 using xhci_hcd
[ 2291.598626] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b96c0
[ 2291.598638] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b90c0
[ 2291.598644] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b9440
[ 2291.600952] logitech-djreceiver 0003:046D:C52B.0014: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-2/input2
[ 2291.610449] input: Logitech Unifying Device. Wireless PID:401a as /devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2:1.2/0003:046D:C52B.0014/input/input12
[ 2291.610596] logitech-djdevice 0003:046D:C52B.0017: input,hidraw1: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless PID:401a] on usb-0000:00:14.0-2:1
Comment 27 Benjamin Tissoires 2013-08-06 09:55:49 EDT
@Zach Carter:

yes, the patch is on its way to Linus, so hopefully it will be in the next rc.

@mock:

yes, this is normal given the way the driver is written.
Comment 28 Benjamin Tissoires 2013-08-06 16:11:27 EDT
*** Bug 994227 has been marked as a duplicate of this bug. ***
Comment 29 Carlos Almeida 2013-08-07 10:16:05 EDT
For me on Fedora 19 with "Anywhere MX" after upgrading from 3.9.x to 3.10.4 the mouse stops working. 
From the previous comments it should be fixed via workaround patch on 3.10.4, so after some research I found that mouse works again if I "unpair & pair" it again.

You can do that on Fedora 19 with "ltunify", so on my system I fixed the problem with:

# git clone https://git.lekensteyn.nl/ltunify.git
# cd ltunify
# make
cc -g -O2 -Wall -Wextra -D_FORTIFY_SOURCE=2 -fstack-protector --param ssp-buffer-size=4  -o ltunify ltunify.c
cc -g -O2 -Wall -Wextra -D_FORTIFY_SOURCE=2 -fstack-protector --param ssp-buffer-size=4  -o read-dev-usbmon read-dev-usbmon.c
# ./ltunify list
Devices count: 1
Connected devices:
idx=1	Mouse	Anywhere MX

" Not Working at this stage"

# ./ltunify -d /dev/hidraw0 unpair 1
Device 0x01 Mouse successfully unpaired
# ./ltunify -d /dev/hidraw0 pair 10
Please turn your wireless device off and on to start pairing.
Found new device, id=0x01 Mouse
# ./ltunify list
Devices count: 1
Connected devices:
idx=1	Mouse	Anywhere MX

Working again!

So if you are on kernel 3.10.4 and mouse is not working yet try "unpair/pair" and see if that also fixes the issue 

Regards,
\\CA,
Comment 30 gcarter 2013-08-07 11:57:33 EDT
I indeed have tried this and it works.

ltunify.c seems to have enough code in it to make it useful in creating a plugin control for the KDE mouse settings since it looks like you can check on status/etc of the pairing.

The code should be trivial.  I will see what I can cook up and get back to you.

Very nice, thank you.

-gc
Comment 31 Benjamin Tissoires 2013-08-07 12:04:55 EDT
guys, please do not do such hackish way to fix this problem. I know that you can not use your mouse right now, but it is a matter of days or even hours.
So, please, if you want to use your mouse, the simplest way is to run a previous 3.9 fedora kernel, and you will be just fine.

BTW, if you want to make a KDE plugin with ltunify, I'm ok, but don't say that this is the solution to fix the current problem.
Comment 32 Zach Carter 2013-08-07 13:31:44 EDT
I installed the following kernel-3.10.5-201.fc19 build and the problem is fixed there, no hacks needed:

http://koji.fedoraproject.org/koji/buildinfo?buildID=454939
Comment 33 Zach Carter 2013-08-07 13:36:08 EDT
(In reply to Carlos Almeida from comment #29)

> # git clone https://git.lekensteyn.nl/ltunify.git

ltunify is already part of fedora, so you should be able to avoid the compile and just do "yum install ltunify"
Comment 34 gcarter 2013-08-07 14:20:33 EDT
Yes, I see that.

However, the version in the repo is too old.

The one in GIT allowed me to unpair etc.

Also, the GIT version seems to have a lot of status query possibilities with the unify driver, making it suitable for a gui interface.

-gc
Comment 35 Ed Marshall 2013-08-07 14:36:12 EDT
Just FYI: using the version already in Fedora, I was able to unpair/pair successfully, and it "fixed" the problem for me.

But I also agree with Benjamin, the correct fix here is to get a kernel out that fixes the issue.
Comment 36 Fedora Update System 2013-08-07 16:47:39 EDT
kernel-3.10.5-201.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/kernel-3.10.5-201.fc19
Comment 37 gcarter 2013-08-07 20:12:14 EDT
Just out of curiosity, what GIT submission ID fixed the issue for upcoming 3.10.6?

-gc
Comment 38 Garry T. Williams 2013-08-07 21:51:47 EDT
(In reply to Zach Carter from comment #32)
> I installed the following kernel-3.10.5-201.fc19 build and the problem is
> fixed there, no hacks needed:
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=454939

Confirmed.  This fixes the regression.
Comment 39 Fedora Update System 2013-08-09 13:12:04 EDT
kernel-3.10.5-201.fc19 has been pushed to the Fedora 19 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.