You are not logged in.

#1 2019-08-30 01:31:04

bztarch
Member
Registered: 2019-08-30
Posts: 8

Mouse lag

Hi,

I'm using Arch Linux for several years now. Recently I'm having a serious issue with USB mice, it's lagging, randomly freezing to the point I can't use the pointer. I usually do the homework, search the net for answers and I'm usually able to solve the issues on my own. But not this time, and it's very annoying, and renders my Linux box useless.

The problem started about a month ago with a Syu. Ever since the mouse is brutally lagging, all the time, even after a fresh restart (so not just after returning from sleep). I've tried:
1. more mice.
2. different USB ports
3. mouse connected through an USB hub
4. setting usb hid's poll interval to 1kHz, and also tried turning poll off with /etc/modprobe.d conf
5. turning power management to auto using powertop (setting it to "on" just kills the mouse for good)
6. I've checked another box with an about two months old Arch, all mice works like a charm
7. I ain't using any DE just openbox, so I haven't tried those answers with DE specific configurations
8. the CPUs are relaxed, the load is barely registering (below 5% and that's mostly top)
9. I haven't run out of software interrupts either

I've absolutely no problem with the usb keyboard, and I'm keep seeing "usb hid disconnect" and then immediately "usb hid reconnect" in dmesg's output when the pointer freezes.
I would appreciate if any of you could point me in the right direction, because I'm out of ideas. I'm sure it's the Linux kernel's USB hid driver misbehaving cutting power from the mouse, but how to avoid that?

Thanks,
bzt

ps: dmesg output (repeats many many times):
[18393.416078] usb 3-2: USB disconnect, device number 46
[18393.706041] usb 3-2: new low-speed USB device number 47 using uhci_hcd
[18393.899068] usb 3-2: New USB device found, idVendor=046d, idProduct=c018, bcdDevice=43.01
[18393.899072] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[18393.899075] usb 3-2: Product: USB Optical Mouse
[18393.899077] usb 3-2: Manufacturer: Logitech
[18393.915532] input: Logitech USB Optical Mouse as /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/0003:046D:C018.002C/input/input52
[18393.915660] hid-generic 0003:046D:C018.002C: input,hidraw2: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:1a.0-2/input0
[18421.039391] usb 3-2: reset low-speed USB device number 47 using uhci_hcd
[18422.402794] usb 3-2: USB disconnect, device number 47
[18422.679369] usb 3-2: new low-speed USB device number 48 using uhci_hcd
[18422.868402] usb 3-2: New USB device found, idVendor=046d, idProduct=c018, bcdDevice=43.01
[18422.868406] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[18422.868409] usb 3-2: Product: USB Optical Mouse
[18422.868412] usb 3-2: Manufacturer: Logitech
[18422.884882] input: Logitech USB Optical Mouse as /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/0003:046D:C018.002D/input/input53
[18422.885009] hid-generic 0003:046D:C018.002D: input,hidraw2: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:1a.0-2/input0

(note: problem not tied to this specific mouse, I've tried wired, bluetooth mice, all the same)

Offline

#2 2019-08-30 05:55:20

seth
Member
Registered: 2012-09-03
Posts: 20,430

Re: Mouse lag

I'm sure it's the Linux kernel's USB hid driver misbehaving cutting power from the mouse, but how to avoid that?

https://wiki.archlinux.org/index.php/Po … utosuspend

I'd first globally deactivate it to see whether that's the cause.
nb. that power managing tools (TLP, powertop on autotune, …) would potentially alter this at runtime so you want to check, whether such tool causes the problem itfp. by completely deactivating (or w/ the broadsword: removing the package) it.

Offline

#3 2019-08-30 11:01:00

bztarch
Member
Registered: 2019-08-30
Posts: 8

Re: Mouse lag

Hi,

seth wrote:

I'm sure it's the Linux kernel's USB hid driver misbehaving cutting power from the mouse, but how to avoid that?

https://wiki.archlinux.org/index.php/Po … utosuspend

I'd first globally deactivate it to see whether that's the cause.
nb. that power managing tools (TLP, powertop on autotune, …) would potentially alter this at runtime so you want to check, whether such tool causes the problem itfp. by completely deactivating (or w/ the broadsword: removing the package) it.

Thanks for the answer. That wiki page was the first thing I read, so unfortunately I've already put that udev rule in place, and it does not solve the problem.

/etc/udev/rules.d/50-usb_power.rules
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"

Just for the records, this has exactly the same effect as using powertop's Tunables tab.

Before I've posted, I've already created

/etc/modprobe.d/usbpower.conf
options usbcore autosuspend=-1

Because of your post, I've double checked, and to my biggest surprise it turned out this conf does not work. Contents of /sys/module/usbcore/parameters/autosuspend did not change, remained 2 after reboot.
However, if I execute

sudo bash -c "echo -1 >/sys/module/usbcore/parameters/autosuspend"

manually, then it changes for good, and the mouse lag problem goes away.

I'm really curious why this modprobe conf isn't working. Other modprobe options are okay and loading as they should (have double checked those too), and this usbpower.conf file has exactly the same owner and access rights as the rest. There's no typo in the file. I've also tried to use large values (like 3600), they are not set either, so it's not a -1 parsing issue. I'm not using any power mangling tool (this is a desktop PC, I've haven't installed any powermanagement except powertop lately which I've executed in the foreground only but not since the last reboot). What packages should I look for? I see no daemons running in "ps aux" output. There's only dbus-daemon, nothing else (I'm using openbox only started from xinitrc, no KDE, GNOME, LXDE etc).

Also turning autosuspend off does not solve the original problem, why are USB mice powered off randomly all the time. I'd like to stress out that I'm using the same hw for years now, and the problem appeared only recently with a kernel refresh, and it is presistent with several mice.

Thanks,
bzt

Offline

#4 2019-08-30 11:57:43

seth
Member
Registered: 2012-09-03
Posts: 20,430

Re: Mouse lag

The module is probably loaded in the initramfs, try passing the parameter on the command line. If that doesn't work either, the value is rather reset then not set at all.
If it does work, simply regenerate the initramfs. Check "lsinitcpio /boot/initramfs-linux.img | grep modprobe.d" (nb. that the initramfs name may differ, depending on your kernel)

Your udev rule activates global autosuspend, but what you wanted to do was to add a rule that explicitly disables it for the mouse. The rule and your related powertop comment make me wonder whether that's actually the source of the problem?

Offline

#5 2019-08-31 09:48:35

bztarch
Member
Registered: 2019-08-30
Posts: 8

Re: Mouse lag

seth wrote:

The module is probably loaded in the initramfs, try passing the parameter on the command line. If that doesn't work either, the value is rather reset then not set at all.
If it does work, simply regenerate the initramfs. Check "lsinitcpio /boot/initramfs-linux.img | grep modprobe.d" (nb. that the initramfs name may differ, depending on your kernel)

Hey, thanks, that was it! All the modprobe conf files were in the archive, except for usbpower.conf. I ran mkinitcpio and now autosuspend is set to -1 after reboot. Thanks!
Maybe it would be good to put a remainder on the wiki page. I bet there are others who forget to regenerate the initramfs like me :-)

seth wrote:

Your udev rule activates global autosuspend, but what you wanted to do was to add a rule that explicitly disables it for the mouse. The rule and your related powertop comment make me wonder whether that's actually the source of the problem?

Actually no, this is what I want. I only have a keyboard and a mouse attached, and occasionally a stick, neither of which I want to power off. I'll physically disconnect the USB stick if I want it powered down, and I don't want hid devices to be suspended ever.

Yeah, I'm also very curious what the problem is. Now with autosuspend -1, my original mouse (which I've been using with this machine for two years) works for a while, but after a couple of hours, it starts disconnecting/reconnecting again. With the other mouse the problem does not appear (at least, not yet, let's see if it's still working tomorrow). Fingers crossed. What's really strange is, that both mice on another box with an older kernel works. This must be an uhci or hid driver issue in the kernel.

Thank you,
bzt

Offline

#6 2019-08-31 10:49:16

seth
Member
Registered: 2012-09-03
Posts: 20,430

Re: Mouse lag

Ahemm…

seth wrote:

Your udev rule activates global autosuspend

Offline

#7 2019-09-22 11:33:10

bztarch
Member
Registered: 2019-08-30
Posts: 8

Re: Mouse lag

First, thank you for your help.

seth wrote:

Ahemm…

seth wrote:

Your udev rule activates global autosuspend

Well, and how to deactive? It's activated by default. It seems to only understand "on" and "auto". I get "invalid argument" error with "off". However I've removed the udev rule entirely, and left only the usbcore module option in the initramfs.

This worked, up until the latest Syu. With the recent kernel (5.3.1-arch1-1) the mouse lag turned into a complete freeze. If I connect any USB mice it works for a short time, then it stops completely. In the dmesg I can see "USB disconnect" for some reason (I haven't disconnected the mouse). If I physically disconnect and reconnect, then the mouse works again for a while, then stops.

And again, module options doesn't work since the update. This time I've checked the initramfs, and the usbpower.conf is there. And again, if I manually set /sys/module/usbcore/paramter/autosuspend to '-1', the problem goes away. I have a feeling module option is passed on boot as it should, but maybe later something is overwriting it to '2'?

It must be something trivial I'm missing here. I'd like to disable USB power management entirely and permanently (as I wrote before, I only have HIDs and occasionally sticks, I don't need power management for them at all).

Thanks,
bzt

Last edited by bztarch (2019-09-22 11:34:47)

Offline

#8 2019-09-22 14:06:34

seth
Member
Registered: 2012-09-03
Posts: 20,430

Re: Mouse lag

Autosuspend is probably auto by default for the hubs, but not for individual devices.
You can also set the power/autosuspend value to -1 in this ruleto effectively disable autosuspend as is mentioned by

wiki wrote:

Similarly to power/control, the delay time can be fine-tuned per device by setting the power/autosuspend attribute.

You might have to do this for the hub as well.

something is overwriting it to '2'?

Most likely, all PM services (TLP, laptop-mode-tools, powertop autotuning, maybe some DE services) are prone to cause this.
The specific device value would however overrule it.

Offline

#9 2019-09-25 23:19:07

bztarch
Member
Registered: 2019-08-30
Posts: 8

Re: Mouse lag

Thanks for your help!

seth wrote:

Autosuspend is probably auto by default for the hubs, but not for individual devices.

Nope, it is "auto" for ALL devices and hubs.

seth wrote:

You can also set the power/autosuspend value to -1 in this ruleto effectively disable autosuspend

I know, I just don't want to do that manually after every reboot. Module config worked before the last update, but not after. There must be a way to set usbcore's parameter permanently. TBH idk why /etc/modprobe.d stopped working after the update (the usbpower.conf is in the initrd).

seth wrote:

You might have to do this for the hub as well.

I don't use hub. Just for the record, I've tried with a hub too, same result, worked with usbcore.autosuspend -1 (I didn't had to set the hub's parameter)

seth wrote:

something is overwriting it to '2'?

Most likely, all PM services (TLP, laptop-mode-tools, powertop autotuning, maybe some DE services) are prone to cause this.
The specific device value would however overrule it.

The problem is, I don't have TLP, laptop-mode-tools nor powertop autotuning installed. I've removed powertop entirely, haven't installed the rest in the first place (desktop computer). And I'm an old-fashioned UNIX guy, I hate DEs, so I don't have any as I said (openbox only running from xinitrc).

How can I find out which process is overwriting the usbcore's autosuspend value? Which packages to look for? There's nothing in systemctl's output that would resemble a power management service. Any grep pattern to use on dmesg or syslog messages?

Thanks,
bzt

Offline

#10 2019-09-26 06:16:08

seth
Member
Registered: 2012-09-03
Posts: 20,430

Re: Mouse lag

A "hub" does not equate to a physical external replicator and I'm pretty sure that your system has 1-4 hubs, try "lsusb" ;-)

I'd first check teh status when only booting the rescue.target, https://wiki.archlinux.org/index.php/Sy … _boot_into
You can audit /sys/module/usbcore/parameters/autosuspend : https://wiki.archlinux.org/index.php/Au … ies_access

Offline

#11 2019-09-26 12:25:38

bztarch
Member
Registered: 2019-08-30
Posts: 8

Re: Mouse lag

seth wrote:

A "hub" does not equate to a physical external replicator and I'm pretty sure that your system has 1-4 hubs, try "lsusb" ;-)

Nope, only one root per port, and all set to "auto". But that's okay, setting usbcore's autosuspend manually works, so I don't have to care about hubs, root or not :-)

seth wrote:

I'd first check teh status when only booting the rescue.target, https://wiki.archlinux.org/index.php/Sy … _boot_into
You can audit /sys/module/usbcore/parameters/autosuspend : https://wiki.archlinux.org/index.php/Au … ies_access

Thank you very much, I'll check these!

Thanks,
bzt

Offline

Board footer

Powered by FluxBB