You are not logged in.
After upgrading the kernel to 6.17.8 my mouse stopped working over my usb hub. It intermittently disconnects without any journal entry. In my solaar logs you can see frequent disconnects:
2025-11-15 05:20:10,791,791 DEBUG [SolaarListener:hidraw1] logitech_receiver.base: (32) => r[10 02 8F00 180900]
2025-11-15 05:20:10,791,791 DEBUG [SolaarListener:hidraw1] logitech_receiver.device: pinged 2: online False protocol None present True
2025-11-15 05:20:10,791,791 INFO [SolaarListener:hidraw1] solaar.listener: status_changed <Device(2,1017,Anywhere Mouse MX,ACACF79B)>: paired offline (0)
2025-11-15 05:20:10,791,791 DEBUG [SolaarListener:hidraw1] logitech_receiver.notifications: <Device(2,1017,Anywhere Mouse MX,ACACF79B)> (1.0) DJ Notification(20,2,42,01,0000000000000000000000)
2025-11-15 05:20:10,791,791 INFO [SolaarListener:hidraw1] logitech_receiver.notifications: <Device(2,1017,Anywhere Mouse MX,ACACF79B)>: DJ connection: False Notification(20,2,42,01,0000000000000000000000)
2025-11-15 05:20:10,791,791 DEBUG [MainThread] solaar.ui: status changed: <Device(2,1017,Anywhere Mouse MX,ACACF79B)> (0) None
2025-11-15 05:20:10,791,791 DEBUG [MainThread] solaar.ui.icons: battery icon for 65:False = battery-good
2025-11-15 05:20:10,791,791 DEBUG [SolaarListener:hidraw1] logitech_receiver.device: device 2 changing: active=False False present=True
2025-11-15 05:20:10,791,791 DEBUG [SolaarListener:hidraw1] logitech_receiver.device: device 2 changed: active=False Battery(level=65, next_level=None, status=<BatteryStatus.DISCHARGING: 0>, voltage=None, light_level=None)
2025-11-15 05:20:10,791,791 DEBUG [SolaarListener:hidraw1] logitech_receiver.base: (32) pinging device 2
2025-11-15 05:20:10,791,791 DEBUG [SolaarListener:hidraw1] logitech_receiver.base: (32) <= w[10 02 0019 000072]
2025-11-15 05:20:10,791,791 DEBUG [MainThread] solaar.ui.tray: picked device with lowest battery: ('/dev/hidraw1', 2, 'Anywhere Mouse MX', <Device(2,1017,Anywhere Mouse MX,ACACF79B)>)
2025-11-15 05:20:10,791,791 DEBUG [MainThread] solaar.ui.icons: battery icon for 65:False = battery-good
2025-11-15 05:20:10,792,792 DEBUG [MainThread] solaar.ui.icons: battery icon for 65:False = battery-good
2025-11-15 05:20:10,795,795 DEBUG [SolaarListener:hidraw1] logitech_receiver.base: (32) => r[10 02 8F00 190900]
2025-11-15 05:20:10,795,795 DEBUG [SolaarListener:hidraw1] logitech_receiver.device: pinged 2: online False protocol None present True
2025-11-15 05:20:10,795,795 INFO [SolaarListener:hidraw1] solaar.listener: status_changed <Device(2,1017,Anywhere Mouse MX,ACACF79B)>: paired offline (0) disconnected
2025-11-15 05:20:10,795,795 DEBUG [MainThread] solaar.u
these do not happen when the same receiver is connected directly to my desktop.
Last edited by vls-xy2 (2025-11-25 01:46:57)
Offline
Smells like https://wiki.archlinux.org/title/Power_ … utosuspend which doesn't get excepted for the hubs VID:PID ?
Offline
After upgrading the kernel to 6.17.8
What was the last good version?
Does downgrading help?
It intermittently disconnects without any journal entry.
So no "USB disconnect, device number X" ?
Offline
I believe the last working kernel was 6.17.7, but am not sure. Did not try a downgrade yet, may also be related to other packages. I did try tinker with the autosuspend rules but did not find a udev rule that seemed to work.
Offline
"usbcore.autosuspend=-1" would disable it globally (unless some power saving like TLP interferes)
https://wiki.archlinux.org/title/Kernel_parameters
But absolutely try to restore the previous state w/ a kernel downgrade and if that works, the journals might show a relevant difference.
If not, try to roll back the entire compromising update and if that still doesn't change anything, maybe the behavior is coincidental and relates to the batteries in the mouse?
Offline
Thank you for the responses! The kernel parameter "usbcore.autosuspend=-1" did not bring any change. Nor did downgrading just the kernel to a couple of versions before. Perhaps I need to downgrade also the headers or other packages? It has worked as recently as the previous system update and the whole setup works on a windows machine fine I did swap the batteries just in case. The usb hub is part of my display and I regularly swap between pc's. Interestingly I noticed that when I move the mouse, the keyboard input starts to lag too (both are using the same unifying receiver) as if the datarate is somehow throttled.
Last edited by vls-xy2 (2025-11-17 04:59:15)
Offline
It has worked as recently as the previous system update
What exactly was in that update? See /var/log/pacman.log
the whole setup works on a windows machine fine
*a* windows machine or *this* machine running windows?
I noticed that when I move the mouse, the keyboard input starts to lag too (both are using the same unifying receiver) as if the datarate is somehow throttled.
Radio interference? Are the external hub and the directly used slot somewhat in the same physical location (and not separated by some EM shield like a PC case)?
Or is this the case regardless where the dongle is attached?
Offline
sooo after leaving it be for a while the problem seems to have solved itself.
At least after a few update cycles things are now working normally again. Thanks for the help. @Seth, all valid questions but posting the whole update log would be a bit futile since this machine has a lot of things installed and updated at the same time (>10 years old now). The whole setup worked for pretty flawlessly (hdmi sound being a bit of an issue early on) throughout.
The mouse disconnects were only seen when on a usb hub (a dell monitor connected via display port and usb).
Offline
\o/
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.
(You might have to shorten the present subject a bit)
Offline
I guess I was a bit too optimistic, after using my computer a bit more I found that the problem is persisting. I have in the meantime tried a different usb-hub. It is just my monitor: DELL U3821DW, that sometimes causes this problem. Less frequently than before I guess.
Offline
The monitor might cut usb power on DPMS (certainly if you turn it off)?
Offline
It probably does, but not sure what is happening. The USB is connected via a separate cable fro the display port (sticking in an nvidida (sry)). I usually now resort to switching the dongle instead of just using the monitor as a kvm-switch which is a bummer but my laptop is not really getting enough power over the usb-c (as the old ones did back in the day). Lot's of particulars in this setup :-/ and probably just as many options to mitigate.
Offline
So with my latest update which included (but is not limited to) linux-headers (6.18.5.arch1-1 -> 6.18.6.arch1-1) it definitely is solved. Unfortunately, I can't really pin down the cause or solution. Lot's of packages have been updated in the mean time.
Offline