Bugzilla – Bug 1217172
Logitech-Keyboard stops working after login
Last modified: 2023-12-12 11:41:08 UTC
Since the last kernel-update to 6.6.1, my Logitech G510 stops working after log in to Gnome (no key-presses registered, num-lock stuck on the previous state). The keyboard is connected via usb-switch. Booting to an older 6.5.9 temporary solved it again. I also found some related bug reports, mentioning other Logitech- and also the G510-keyboard: https://bbs.archlinux.org/viewtopic.php?id=290172 (c#10 seems to have some pointers on the problematic commit) https://bugs.archlinux.org/task/80133 https://bugzilla.kernel.org/show_bug.cgi?id=218094 https://bbs.archlinux.org/viewtopic.php?id=287927 Please let me know if you need any logs or additional information.
Created attachment 870769 [details] Potentially related journal messages during boot journalctl -o short-precise -k -b -1
It seems that the upstream commit 9d1bd9346241cd6963b58da7ffb7ed303285f684 HID: logitech-dj: Add support for a new lightspeed receiver iteration caused a regression. I'm building a test kernel with the revert of the commit. It's being built in OBS home:tiwai:bsc1217172 repo. Please give it a try later once after the build finishes.
Takashi, thanks for the fast reply. I installed 6.6.1-1.1.g2044391 from your repo, unfortunately the behavior is still the same. I'll attach the new logs to the bug.
Created attachment 870776 [details] Logitech error with test-kernel journalctl -o short-precise -k -b
OK, thanks, then it's a different bug from the bugzilla.kernel.org entries. Rather it's relevant with the Arch's entry, something about leds class changes. The Arch entry (https://bbs.archlinux.org/viewtopic.php?id=290172) suggested the upstream commit 43a707ae58406200597b03a5be782e726b3c175b leds: Make leds_class a static const structure as the culprit. Another test kernel with the revert of this commit is being built in OBS home:tiwai:bsc1217172-2 repo. Please give it a try later. (Though, I doubt that it's a false-positive bisection result, judging from the commit change. But it's better to double-check with the actual revert.)
Also, could you give the dmesg outputs from both working (6.5.x) and non-working (6.6.1) kernels, as well as hwinfo outputs from both of them?
Created attachment 870777 [details] dmesg with kernel 6.5.9
Created attachment 870778 [details] hwinfo with kernel 6.5.9
Created attachment 870779 [details] dmesg with kernel 6.6.1
Created attachment 870780 [details] hwinfo with kernel 6.6.1
I'll give the new test-kernel a try as soon as it's built or latest tomorrow morning.
6.6.1-1.1.g71674cf unfortunately hasn't resolved it as well. I'll upload the new hwinfo and dmesg afterwards.
Created attachment 870782 [details] dmesg with kernel 6.6.1-1.1.g71674cf
Created attachment 870783 [details] hwinfo with kernel 6.6.1-1.1.g71674cf
Thanks for quick testing. It's no surprise that the revert patch didn't work (although the problem must be related with some changes in leds class drivers). I made a quick hack to name the leds device unique per hid/input device for avoiding the sysfs name conflict. A test kernel is being built in OBS home:tiwai:bsc1217172-3 repo. Please give it a try later.
Sorry that it took a bit longer. I tested it with the new kernel and sadly still the same result. Also, I strangely still see the sysfs conflict in dmesg.
Created attachment 870801 [details] dmesg with kernel 6.6.1-1.gf1daf70
Created attachment 870802 [details] hwinfo with kernel 6.6.1-1.gf1daf70
Hmm, it's puzzling. Then it means that the conflict happens within the same HID device probe? Now I added some debug prints and also let the driver to ignore the led class registration error. Another test kernel is being built in OBS home:tiwai:bsc1217172-4. Let's see.
Thanks again for the fast reply. It seems OBS is down at the moment. I'll give it a try tomorrow morning.
I just tested 6.6.1-2.gc9735e0 and with ignoring the led class registration error, the keyboard works again! Thank you very much! I'll attach the hwinfo and dmesg of the working kernel and in case this is not the final fix, just let me know and I'll happily give it another test.
Created attachment 870815 [details] dmesg with working kernel 6.6.1-2.gc9735e0
Created attachment 870816 [details] hwinfo with working kernel 6.6.1-2.gc9735e0
OK, thanks, now finally I understood what's going on. The problem is that leds class gained the sysfs entry "color" in the commit c7d80059b086c4986cd994a1973ec7a5d75f8eea leds: class: Store the color index in struct led_classdev Meanwhile, hid-lg-g15 driver creates the own sysfs entry "color", and this conflicts with the new standard one in the above. A fix would be to rename either of them. I'm building a test kernel with the rename of the hid-lg-g15's one (from "color" to "kbd_color"), and this should avoid the conflict. Another test kernel with the patch is being built in OBS home:tiwai:bsc1217172-5 repo. Please give it a try later again.
Created attachment 870817 [details] A workaround patch
Seems like the naming of the led-class was really the reason. 6.6.1-1.g01080f1 works as well. Thank you very much for your efforts!
Created attachment 870818 [details] dmesg with working kernel 6.6.1-1.g01080f1
Created attachment 870820 [details] hwinfo with working kernel 6.6.1-1.g01080f1
We ended up rather with the revert of the affecting commit in leds core: https://lore.kernel.org/r/20231121142629.27083-1-tiwai@suse.de Now I backported the revert patch to stable branch.
(In reply to Takashi Iwai from comment #29) > We ended up rather with the revert of the affecting commit in leds core: > https://lore.kernel.org/r/20231121142629.27083-1-tiwai@suse.de ... and this turned out to break the build. A partial revert was submitted to the upstream instead: https://lore.kernel.org/r/20231121162359.9332-1-tiwai@suse.de The patch was backported to TW stable branch now.
I just tested it with 6.6.3 and everything is working as expected. Thanks Takashi for your help!