Everything was working great until an update a couple of weeks ago. I even reinstalled from fedora iso without updating it and everything works fine all day. as soon as i update I start having the following issue:
I have a Dell Thunderbolt dock. monitors are working fine all the time
the problem is my logitech keyboard and mouse using the unified receiver stop responding.
when checking dmesg, I don’t see any errors or messages pass the connected message. if i disconnect the receiver and plug it back in things work again.
If I plug the receiver directly on my laptop then i don’t see any issue but that defeats the purpose of having a dock.
I am not sure which update broke things since i don’t use my laptop docked all the time.
I don’t see anything wrong from dmesg
the disconnect is when i pull the dungle and reconenct it again
[ 72.791278] logitech-hidpp-device 0003:046D:407B.000C: HID++ 4.5 device connected.
[ 73.915312] warning: `ThreadPoolForeg' uses wireless extensions which will stop working for Wi-Fi 7 hardware; use nl80211
[ 178.843395] usb 1-9: reset full-speed USB device number 4 using xhci_hcd
[ 287.547795] usb 7-1.3: USB disconnect, device number 5
[ 288.501197] usb 7-1.3: new full-speed USB device number 6 using xhci_hcd
[ 288.702983] usb 7-1.3: New USB device found, idVendor=046d, idProduct=c52b, bcdDevice=24.11
[ 288.702987] usb 7-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 288.702988] usb 7-1.3: Product: USB Receiver
[ 288.702988] usb 7-1.3: Manufacturer: Logitech
[ 288.724654] logitech-djreceiver 0003:046D:C52B.0010: hiddev96,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:a9:00.0-1.3/input2
[ 288.839896] input: Logitech MX Vertical as /devices/pci0000:00/0000:00:1d.0/0000:6d:00.0/0000:6e:03.0/0000:a4:00.0/0000:a5:04.0/0000:a7:00.0/0000:a8:01.0/0000:a9:00.0/usb7/7-1/7-1.3/7-1.3:1.2/0003:046D:C52B.0010/0003:046D:407B.0011/input/input47
[ 288.840327] logitech-hidpp-device 0003:046D:407B.0011: input,hidraw4: USB HID v1.11 Keyboard [Logitech MX Vertical] on usb-0000:a9:00.0-1.3/input2:1
[ 288.861754] logitech-djreceiver 0003:046D:C52B.0010: device of type eQUAD step 4 DJ (0x04) connected on slot 2
[ 288.873838] logitech-hidpp-device 0003:046D:407B.0011: HID++ 4.5 device connected.
[ 289.269954] input: Logitech ERGO K860 as /devices/pci0000:00/0000:00:1d.0/0000:6d:00.0/0000:6e:03.0/0000:a4:00.0/0000:a5:04.0/0000:a7:00.0/0000:a8:01.0/0000:a9:00.0/usb7/7-1/7-1.3/7-1.3:1.2/0003:046D:C52B.0010/0003:046D:4088.0012/input/input48
[ 289.270133] logitech-hidpp-device 0003:046D:4088.0012: input,hidraw5: USB HID v1.11 Keyboard [Logitech ERGO K860] on usb-0000:a9:00.0-1.3/input2:2
[ 290.276075] logitech-hidpp-device 0003:046D:4088.0012: HID++ 4.5 device connected.
any clues on what I can do to troubleshoot this issue will be greatly appreciated.
thank you in advance
You might have to look if you still have different kernel versions you could boot of.
Kernel: 6.10.8-200.fc40.x86_64
It seams that a kernel change introduced an old issue a “regression” again.
Can you please test, while booting pressing ESC key, to select an older Kernel version? If it is a regression we need to know exactly when it started again.
I searched about “device of type eQUAD step 4 DJ” from your dmesg:
I tried to use firmware updated and did not find any new firmware
sudo fwupdmgr update
Devices with no available firmware updates:
• Touchpad
• Dell WD15/TB16/TB18 wired Dock
• Dell WD15/TB16/TB18 wired Dock
• Fingerprint Sensor
• TPM
• Thunderbolt Cable
• Thunderbolt Dock
• UEFI Device Firmware
• USB4 host controller
• USB4 host controller
• Unifying Receiver
Devices with the latest available firmware version:
• PM9A1 NVMe Samsung 1024GB
• System Firmware
• UEFI Device Firmware
• UEFI dbx
I booted up on kernel 6.10.6-200.fc40.x86_64 (i have 6.10.6 6.10.7 and 6.10.8 )
and initially it stopped working twice but now it has been working fine.
I then booted into 6.10.7-200.fc40.x86_64 and it did the same, failed a couple of times but then it worked as expected. At least it has worked for 30 mins uninterrupted.
I won’t be on my office for the next week so I won’t be able to test more but 6.10.8 seems to be the problem.
One thing I noticed during one of the disconnects, I was typing and it got stuck on one letter, it kept repeating the letter until I removed the receiver.
@ilikelinux To add to this mystery. I am travelling and just realized my sound card stopped working with 6.8 I also just got 6.10.9 and that one still breaks my audio (speakers and mic)
I set my default kernel to 6.7 and that has been working so far for everything @up-n-atom
I would like some clarification.
Is this problem only when the receiver is plugged into the dock or does it occur when plugged directly into the laptop as well.?
I have seen intermittent issues with my logitech devices ONLY when a battery is nearing end of life and the problems disappear when the batteries are replaced so the device has full power radio signals. I use that type performance as a signal that I must replace the batteries.
Sometimes the simplest things are what we overlook when doing troubleshooting.
I am leaning towards driver issue, to trouble shoot this, I reinstalled fedora and did not update for a few days. everything was stable and working as expected. as soon as i ran an update, i started to have issues again with my dock.
I think my Logitech unified receiver may be more sensitive to whatever is causing the issue. I also noticed my USB webcam is being unstable but usually recovers without me doing anything. @up-n-atom if you open a new ticket i will follow up with updates there since i think it is just a USB issue and not related specifically to Logitech
Might show some more info. You would have to do it when it works and when it not works so we can compair. This would mean that you probably would need to use devices without wireless connection when the receiver fails.
Radio Frequency Interference (RFI) becomes more of a problem with higher frequencies and will change with device location cable routing, etc. A low battery may lead to a weak signal that doesn’t overcome the cloud of radio-frequency signals generated by modern devices. Apple’s very expensive (US$70+) Thunderbolt 4 cables are probably better designed and tested than the under $15 cables on Amazon.
while I understand this is a possibility my testing really is pointing to a regression in Fedora. I am using my receiver directly on my laptop, rather than on the dock, and it sits next to the TB cable. there are not issues in this configuration. really there has never been an issue in the last 4 years
Ok I was able to capture this commands today. fpaste --sysinfo --printonly |grep -i logitech before and after have the same result
Gathering system info .....................................
Bus 007 Device 005: ID 046d:085c Logitech, Inc. C922 Pro Stream Webcam
Bus 007 Device 006: ID 046d:c52b Logitech, Inc. Unifying Receiver
mei_me kfifo_buf spi_intel i2c_smbus snd industrialio intel_rapl_common mei soundcore processor_thermal_wt_req rfkill processor_thermal_power_floor idma64 processor_thermal_mbox igen6_edac int3403_thermal joydev intel_pmc_core int340x_thermal_zone intel_vsec int3400_thermal pmt_telemetry intel_hid acpi_thermal_rel pmt_class acpi_pad acpi_tad sparse_keymap loop nfnetlink zram dm_crypt hid_logitech_hidpp hid_logitech_dj xe drm_suballoc_helper hid_sensor_hub intel_ishtp_hid nvme nvme_core nvme_auth i915 nouveau rtsx_pci_sdmmc mxm_wmi drm_ttm_helper mmc_core gpu_sched drm_gpuvm crct10dif_pclmul drm_buddy drm_exec crc32_pclmul i2c_algo_bit crc32c_intel ttm polyval_clmulni intel_ish_ipc ucsi_acpi polyval_generic hid_multitouch ghash_clmulni_intel sha512_ssse3 drm_display_helper sha256_ssse3 sha1_ssse3 typec_ucsi rtsx_pci cec intel_ishtp vmd typec i2c_hid_acpi video i2c_hid wmi pinctrl_tigerlake serio_raw ip6_tables ip_tables fuse
fpaste --sysinfo --printonly |grep -i usb on the other hand has interesting differences
before
Gathering system info .....................................
0000:00:14.0 USB controller [0c03]: Intel Corporation Alder Lake PCH USB 3.2 xHCI Host Controller [8086:51ed] (rev 01)
0000:05:00.0 USB controller [0c03]: Intel Corporation Thunderbolt 4 NHI [Maple Ridge 4C 2020] [8086:1137]
0000:39:00.0 USB controller [0c03]: Intel Corporation Thunderbolt 4 USB Controller [Maple Ridge 4C 2020] [8086:1138]
0000:6f:00.0 USB controller [0c03]: Intel Corporation Thunderbolt 4 NHI [Maple Ridge 4C 2020] [8086:1137]
0000:a3:00.0 USB controller [0c03]: Intel Corporation Thunderbolt 4 USB Controller [Maple Ridge 4C 2020] [8086:1138]
0000:a9:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM1042A USB 3.0 Host Controller [1b21:1142]
* USB devices (lsusb):
Bus 001 Device 003: ID 27c6:63ac Shenzhen Goodix Technology Co.,Ltd. Goodix USB2.0 MISC
Bus 007 Device 004: ID 0bda:4014 Realtek Semiconductor Corp. USB Audio
0 [Dock ]: USB-Audio - WD15 Dock
1 [Webcam ]: USB-Audio - C922 Pro Stream Webcam
C922 Pro Stream Webcam at usb-0000:a9:00.0-1.6, high speed
Boot0001* USB NIC (IPV4) PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)/Pci(0x4,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/USB(0,0)/USB(1,0)/MAC(e8b5d0f371a3,0)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0){auto_created_boot_option}
Boot0002* USB NIC (IPV6) PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)/Pci(0x4,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/USB(0,0)/USB(1,0)/MAC(e8b5d0f371a3,0)/IPv6([::],0,Static,[::],[::],64){auto_created_boot_option}
Boot0003* UEFI HTTPs Boot (MAC:E8B5D0F371A3) PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)/Pci(0x4,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/USB(0,0)/USB(1,0)/MAC(e8b5d0f371a3,0)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri(){auto_created_boot_option}
after
Gathering system info .....................................
0000:00:14.0 USB controller [0c03]: Intel Corporation Alder Lake PCH USB 3.2 xHCI Host Controller [8086:51ed] (rev 01)
0000:05:00.0 USB controller [0c03]: Intel Corporation Thunderbolt 4 NHI [Maple Ridge 4C 2020] [8086:1137]
0000:39:00.0 USB controller [0c03]: Intel Corporation Thunderbolt 4 USB Controller [Maple Ridge 4C 2020] [8086:1138]
0000:6f:00.0 USB controller [0c03]: Intel Corporation Thunderbolt 4 NHI [Maple Ridge 4C 2020] [8086:1137]
0000:a3:00.0 USB controller [0c03]: Intel Corporation Thunderbolt 4 USB Controller [Maple Ridge 4C 2020] [8086:1138]
0000:a9:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM1042A USB 3.0 Host Controller [1b21:1142]
* USB devices (lsusb):
Bus 001 Device 003: ID 27c6:63ac Shenzhen Goodix Technology Co.,Ltd. Goodix USB2.0 MISC
Bus 007 Device 004: ID 0bda:4014 Realtek Semiconductor Corp. USB Audio
0 [Dock ]: USB-Audio - WD15 Dock
1 [Webcam ]: USB-Audio - C922 Pro Stream Webcam
C922 Pro Stream Webcam at usb-0000:a9:00.0-1.6, high speed
Sep 25 08:30:20 kernel: usb usb7: root hub lost power or was reset
Sep 25 08:30:20 kernel: usb usb8: root hub lost power or was reset
Sep 25 08:30:20 kernel: usb 7-1: reset high-speed USB device number 2 using xhci_hcd
Sep 25 08:30:20 kernel: usb 8-1: reset SuperSpeed USB device number 2 using xhci_hcd
Sep 25 08:30:20 kernel: usb 7-1.6: reset high-speed USB device number 5 using xhci_hcd
Sep 25 08:30:20 kernel: usb 7-1.3: reset full-speed USB device number 6 using xhci_hcd
Sep 25 08:30:20 kernel: usb 7-1.5: reset high-speed USB device number 4 using xhci_hcd
Sep 25 08:30:20 kernel: r8152-cfgselector 8-1.2: reset SuperSpeed USB device number 3 using xhci_hcd
Sep 25 08:30:21 kernel: usb 1-9: reset full-speed USB device number 3 using xhci_hcd
Boot0001* USB NIC (IPV4) PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)/Pci(0x4,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/USB(0,0)/USB(1,0)/MAC(e8b5d0f371a3,0)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0){auto_created_boot_option}
Boot0002* USB NIC (IPV6) PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)/Pci(0x4,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/USB(0,0)/USB(1,0)/MAC(e8b5d0f371a3,0)/IPv6([::],0,Static,[::],[::],64){auto_created_boot_option}
Boot0003* UEFI HTTPs Boot (MAC:E8B5D0F371A3) PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/Pci(0x3,0x0)/Pci(0x0,0x0)/Pci(0x4,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/USB(0,0)/USB(1,0)/MAC(e8b5d0f371a3,0)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri(){auto_created_boot_option}
this is the interesting part
Sep 25 08:30:20 kernel: usb usb7: root hub lost power or was reset
Sep 25 08:30:20 kernel: usb usb8: root hub lost power or was reset
Sep 25 08:30:20 kernel: usb 7-1: reset high-speed USB device number 2 using xhci_hcd
Sep 25 08:30:20 kernel: usb 8-1: reset SuperSpeed USB device number 2 using xhci_hcd
Sep 25 08:30:20 kernel: usb 7-1.6: reset high-speed USB device number 5 using xhci_hcd
Sep 25 08:30:20 kernel: usb 7-1.3: reset full-speed USB device number 6 using xhci_hcd
Sep 25 08:30:20 kernel: usb 7-1.5: reset high-speed USB device number 4 using xhci_hcd
Sep 25 08:30:20 kernel: r8152-cfgselector 8-1.2: reset SuperSpeed USB device number 3 using xhci_hcd
Sep 25 08:30:21 kernel: usb 1-9: reset full-speed USB device number 3 using xhci_hcd
maybe this is just related to going to sleep and not really the issue… looking at it i see this messages happen way earlier than the actual disconnection
Thanks for the info. I am not sure, to what you refer with, before and after.
Before it got inoperable ore before you re-plugged the receiver?
If possible please edit, so we can see straight what it means.
I see you use beside the receiver from Logitech a cam from the same manufacturer. I guess it is also connected as the dongle on the thunderbolt dock, right?
You might just should remove it (the cam) to see if the interference comes from that, having two/or more devices connected from Logitech.
Please let us know what hardware/device you use without the dock. So we can have a look if this is just
You mentioned also the power saving issue. It could definitely be that when coming back from suspend, the dongle can’t distinguish the devices, and just rejects to work. As I understood you have 3 or more devices from Logitech connected. If you have the chance, to test all the devices connected without dock, would help to find out if we do have to search the problem on the kernel or on the docks firmware.
There have been IIRC several reports of devices attached to a dock that do not wake up after a suspend. I think that was mostly determined to be a result of the system not scanning beyond the docking hub when it wakes up so the devices attached there were not seen.
I am guessing that this might be a similar effect, but only as related to waking up and not the other intermittent issues. It could be that some critical devices are simply not remaining defined on the usb ports of the docking station.
But without guessing and thinking. If this is simply a regress we need to prove that and make it possible to reproduce. And before opening a new bug request we also need to find if there is an old one.
p.s.
If we do have hardware infos we also can have a look on the manufactures page to see if there is a solution/patch/firmware upgrade etc.
sorry, before it got inoperable and after it got inoperable. I will update my post
the camera is a regular USB wired device (this also has intermitent issues but recovers fine). This is what is leading me to believe this is Tunderbolt Hub USB related and not Logitech
without the dock I use the laptop without peripherals. This is my configuration:
Precision 5770
CPU: 12th Gen Intel i7-12800H (20) @ 4.700GHz
GPU: Intel Alder Lake-P GT2 [Iris Xe Graphics]
GPU: NVIDIA RTX A3000 Laptop GPU
Memory: 32GB
with the dock I use the following:
Dock: Dell Thunderbolt TB16
Monitors: LG 34" and Dell 22" ( I have not experienced any issues with them )
Camera: wired USB Logi C922 Pro Stream Webcam
Keyboard and mouse: (through unified receiver) Logi Ergo K860 and MX vertical
I think this was mentioned by someone else. I have not experienced devices disconnecting when coming back from suspend
As a side note:
I re installed fedora from the ISO and everything works. after running the first update things start to randomly disconnect.
I am happy to try anything else to help. If you need me to, I can reinstall the OS.
I am going to try to re do this commands again fpaste --sysinfo --printonly |grep -i logitech and fpaste --sysinfo --printonly |grep -i usb
I will run it as follows:
As soon as the system boots and everything works( with all the peripherals )
As soon as the keyboard and mouse stop working (with all the peripherals)
As soon as the system boots and everything works (without the camera)
As soon as the keyboard and mouse stop working (without the camera)
I will also post the output when the receiver is connected directly to the laptop and the laptop is connected to the Hub
It will probably take me a day to get all this to you
This supports the theory of a regress. This means an older kernel/software works. While updating, the issue is back, because the regress/failure is not patched.
