Bug 1141553 - Logitech unifying receiver not working after update to kernel 3.16.2-200
Summary: Logitech unifying receiver not working after update to kernel 3.16.2-200
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-14 16:05 UTC by Michael Brinkmann
Modified: 2014-10-17 19:56 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-10-17 19:56:09 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Complete dmesg output from working kernel (55.50 KB, text/plain)
2014-09-14 16:05 UTC, Michael Brinkmann
no flags Details
Messages when connecting receiver during boot (55.29 KB, text/plain)
2014-09-18 18:06 UTC, Michael Brinkmann
no flags Details
HID Receiver log for logitech M570 trackball (107.35 KB, text/plain)
2014-09-27 00:13 UTC, mystilleef
no flags Details

Description Michael Brinkmann 2014-09-14 16:05:17 UTC
Created attachment 937359 [details]
Complete dmesg output from working kernel

Description of problem:
While booting with kernel 3.16.2-200 the message 
[    1.920891] logitech-djreceiver 0003:046D:C52B.0003: logi_dj_raw_event: invalid device index: 0
is shown and the system stops working.

When booting with an older kernel eg. 3.15.10-200 the following messages can be found.
[    1.434672] usb 1-1.5: Manufacturer: Logitech
[    1.601637] usb 1-1.6: Manufacturer: Logitech
[    1.887202] logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:1a.0-1.5/input2
[    1.939019] logitech-djreceiver 0003:046D:C52B.0006: hiddev0,hidraw1: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:1a.0-1.6/input2
[    1.989959] input: Logitech Unifying Device. Wireless PID:4003 as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5:1.2/0003:046D:C52B.0003/0003:046D:C52B.0007/input/input5
[    1.990055] logitech-djdevice 0003:046D:C52B.0007: input,hidraw2: USB HID v1.11 Keyboard [Logitech Unifying Device. Wireless PID:4003] on usb-0000:00:1a.0-1.5:2
[    1.992120] input: Logitech Unifying Device. Wireless PID:1025 as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.2/0003:046D:C52B.0006/0003:046D:C52B.0008/input/input6
[    1.992264] logitech-djdevice 0003:046D:C52B.0008: input,hidraw3: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless PID:1025] on usb-0000:00:1a.0-1.6:1

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

How reproducible:
Use Logiech mouse and keyboard with unifying receiver and update to kernel 3.16.2-200

Steps to Reproduce:
1. Just start the system...

Actual results:
System does not start.

Expected results:
System should start.

Additional info:
See attched file

Comment 1 Benjamin Tissoires 2014-09-15 13:56:16 UTC
(In reply to Michael Brinkmann from comment #0)
> Created attachment 937359 [details]
> Complete dmesg output from working kernel

If possible, can you attach the dmesg from the failing kernel?
Maybe you can retrieve it with the journal (IIRC: journalctl -k -b -1)

> 
> Description of problem:
> While booting with kernel 3.16.2-200 the message 
> [    1.920891] logitech-djreceiver 0003:046D:C52B.0003: logi_dj_raw_event:
> invalid device index: 0
> is shown and the system stops working.
> 

This is a false warning (see https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5abfe85c1d4694d5d4bbd13ecc166262b937adf0)

The fact the system stops should not be related to that, the backported patches to stables only fixed security issues. They indeed show false warnings, but this should be solved in the next stable release.

So without a more complete dmesg of the faulty kernel, I can not say much.

Comment 2 Michael Brinkmann 2014-09-18 18:05:29 UTC
Unfortunately the systemd is not started before the crash.
The boot attempts cannot be found with journalctl --list-boots 

The crash has imho something to do with the receiver of the keyboard. When I disconnect it before booting the system and reconnect it during boot it works.

Attached you can find them messages from this booting.

Comment 3 Michael Brinkmann 2014-09-18 18:06:12 UTC
Created attachment 939005 [details]
Messages when connecting receiver during boot

Comment 4 mystilleef 2014-09-26 10:41:23 UTC
I'm having the same problem in Gnome Shell. Except my keyboard, a Logitech K800, works, but my trackball, a Logitech M570, has a complete erratic mind of its own. Clicking any button on the trackball does random things from closing tabs in browsers, to closing apps, to doing absolutely nothing. The Window manager in Gnome Shell is completely unresponsive until I remove the Logitech unifying receiver.

This happened right after the kernel update and I think an xorg driver update for synaptic. 

This is the error in question in my dmesg log.

logitech-djreceiver 0003:046D:C52B.000F: logi_dj_raw_event: invalid device index:255

If you need more info let me know.

System Info:
Fedora 20
Gallium 0.4 on NV98
Linux 3.16.3-200.fc20.x86_64

Comment 5 Benjamin Tissoires 2014-09-26 17:21:31 UTC
Ok, here I am puzzled:
- I have too a fedora 20 box with 2 unifying receivers connected on it (one for a combo keyboard K750 and a mouse M705, and a brand new one for the brand new M750 mentioned in this thread).
- I can boot without any problems, there is no panic of any sort
- I also have a bunch of errors like
logitech-djreceiver 0003:046D:C52B.0007: logi_dj_raw_event: invalid device index:0
logitech-djreceiver 0003:046D:C52B.0004: logi_dj_raw_event: invalid device index:255
But as I said earlier, they are false warnings and should be cut in a next stable release.

So to me, the M750 problem is a hardware failure (please attach hid-recorder recordings[1] of the hidraw device attached to the mouse, not the receiver)

And the boot failure depends on an other USB problem. Is it the only USB device plugged on the machine?

Please also update your kernel to the latest one (I have now a 3.16.3-200.fc20.x86_64) and see if that is still happening.

[1] install hid-replay from https://copr.fedoraproject.org/coprs/bentiss/hid-replay/

Comment 6 mystilleef 2014-09-27 00:13:54 UTC
Created attachment 941733 [details]
HID Receiver log for logitech M570 trackball

HID Receiver log for logitech M570 trackball

Comment 7 mystilleef 2014-09-27 00:21:33 UTC
(In reply to Benjamin Tissoires from comment #5)
> Ok, here I am puzzled:
> - I have too a fedora 20 box with 2 unifying receivers connected on it (one
> for a combo keyboard K750 and a mouse M705, and a brand new one for the
> brand new M750 mentioned in this thread).
> - I can boot without any problems, there is no panic of any sort
> - I also have a bunch of errors like
> logitech-djreceiver 0003:046D:C52B.0007: logi_dj_raw_event: invalid device
> index:0
> logitech-djreceiver 0003:046D:C52B.0004: logi_dj_raw_event: invalid device
> index:255
> But as I said earlier, they are false warnings and should be cut in a next
> stable release.
> 

I have a K800 wireless keyboard and the M570 trackball attached to just one unifying receiver. I notice when I turn off the trackball, everything works well. But when I turn it back on, then chaos. So the problem is definitely the M570 trackball. 

> So to me, the M750 problem is a hardware failure (please attach hid-recorder
> recordings[1] of the hidraw device attached to the mouse, not the receiver)
> 

Might be. I attached the requested log

> And the boot failure depends on an other USB problem. Is it the only USB
> device plugged on the machine?
> 

Yes, it was the only USB device on the machine. One USB unifying receiver linked to the K800 and M570.

> Please also update your kernel to the latest one (I have now a
> 3.16.3-200.fc20.x86_64) and see if that is still happening.
>

Yeap, running the latest. Could this also be related to the x11 synaptic driver update? This problem only really started after the kernel and x11 driver update.

Comment 8 mystilleef 2014-09-27 00:24:01 UTC
One more thing. Solaar, the GUI for managing the Logitech Unifying Receiver, is indicating that the M570 trackball is not encrypted. The K800 keyboard is however. Not sure if this is related.

Comment 9 Benjamin Tissoires 2014-09-29 13:53:17 UTC
(In reply to mystilleef from comment #6)
> Created attachment 941733 [details]
> HID Receiver log for logitech M570 trackball
> 

Thanks. After parsing your reports, it appears that the button 3 is stuck on your trackball (the one on the wheel). So unless there is a mess in the kernel which overwrites it, it looks like a hardware problem to me.

Just to be sure, can you run the old kernel and see if the problem is still there?

(In reply to mystilleef from comment #8)
> One more thing. Solaar, the GUI for managing the Logitech Unifying Receiver,
> is indicating that the M570 trackball is not encrypted. The K800 keyboard is
> however. Not sure if this is related.

That is completely normal:
encryption is used only for keyboards in case someone captures the raw 2.4GHz signals and tries to log the keystrokes. For mice, it does not matters that much so to reduce power consumption, no encryption is used.

Comment 10 Michael Brinkmann 2014-10-13 16:53:30 UTC
The update to kernel 3.16.3-200 makes the problem more random. 
Switching power on... boot... fail... reset... boot... fail... reset... boot... fail... reset... boot... system starts :(

Updating the packages

Oct 11 18:44:27 Updated: bash-4.2.53-1.fc20.x86_64
Oct 11 18:44:34 Updated: 2:libwbclient-4.1.12-5.fc20.x86_64
Oct 11 18:44:36 Updated: 2:samba-libs-4.1.12-5.fc20.x86_64
Oct 11 18:44:38 Updated: 2:samba-common-4.1.12-5.fc20.x86_64
Oct 11 18:44:38 Updated: ibus-libs-1.5.9-2.fc20.x86_64
Oct 11 18:44:39 Installed: python-pyasn1-0.1.7-2.fc20.noarch
Oct 11 18:44:40 Installed: python-pyasn1-modules-0.1.7-2.fc20.noarch
Oct 11 18:44:40 Updated: ibus-gtk3-1.5.9-2.fc20.x86_64
Oct 11 18:44:41 Updated: ibus-wayland-1.5.9-2.fc20.x86_64
Oct 11 18:44:42 Updated: ibus-setup-1.5.9-2.fc20.noarch
Oct 11 18:44:43 Updated: ibus-1.5.9-2.fc20.x86_64
Oct 11 18:44:44 Updated: ibus-gtk2-1.5.9-2.fc20.x86_64
Oct 11 18:44:45 Updated: 2:libsmbclient-4.1.12-5.fc20.x86_64
Oct 11 18:44:46 Updated: 2:samba-winbind-modules-4.1.12-5.fc20.x86_64
Oct 11 18:44:47 Updated: 2:samba-winbind-4.1.12-5.fc20.x86_64
Oct 11 18:44:48 Updated: kernel-tools-libs-3.16.4-200.fc20.x86_64
Oct 11 18:44:49 Updated: libdvdread-5.0.0-1.fc20.x86_64
Oct 11 18:44:50 Updated: jna-4.1.0-7.fc20.x86_64
Oct 11 18:44:50 Updated: jna-contrib-4.1.0-7.fc20.noarch
Oct 11 18:44:51 Updated: libdvdnav-5.0.1-2.20140901gite225924.fc20.x86_64
Oct 11 18:44:52 Updated: kernel-tools-3.16.4-200.fc20.x86_64
Oct 11 18:44:55 Updated: 2:samba-winbind-clients-4.1.12-5.fc20.x86_64
Oct 11 18:44:56 Updated: 2:samba-client-4.1.12-5.fc20.x86_64
Oct 11 18:44:57 Updated: python-ldap-2.4.17-1.fc20.x86_64
Oct 11 18:45:36 Installed: kernel-devel-3.16.4-200.fc20.x86_64
Oct 11 18:45:45 Installed: kernel-3.16.4-200.fc20.x86_64
Oct 11 18:47:02 Updated: VirtualBox-4.3-4.3.18_96516_fedora18-1.x86_64
Oct 11 18:47:03 Updated: perl-DateTime-TimeZone-1.75-1.fc20.noarch
Oct 11 18:47:05 Updated: kernel-headers-3.16.4-200.fc20.x86_64
Oct 11 18:47:06 Updated: tzdata-java-2014h-1.fc20.noarch
Oct 11 18:47:06 Updated: ctags-5.8-16.fc20.x86_64
Oct 11 18:47:08 Updated: tzdata-2014h-1.fc20.noarch
Oct 11 18:47:09 Updated: gstreamer-ffmpeg-0.10.13-14.fc20.x86_64
Oct 11 18:47:10 Updated: efivar-libs-0.13-1.fc20.x86_64

seems to solve the bug. Whatever changed - the hardware definitly not.

Comment 11 mystilleef 2014-10-13 19:14:31 UTC
Latest Fedora kernel solved my problem.


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