After 2023-01-26 update, mouse is intermittently laggy

pgoetz · 2023-01-27 00:40:20

I hadn't updated in over a month because a regression in libx11 1.8.2 was causing all kinds of issues (e.g. firefox freezing and needing to be restarted), so I installed a patched version of libx11 and didn't want to set an IgnorePkg in pacman.conf that I would promptly forget about.

Desktop environment: Mate
Kernel: 6.1.8.arch1-1
Nvidia driver: 525.85.05-2
xorg-server: 21.1.6-1
libx11: 1.8.3-6

Since upgrading, my mouse is intermittently laggy and sluggish. Doesn't matter what I'm running. I've had the mouse freeze for a second with a single terminal open, and I usually have tons of stuff running with no issues.

Has anyone else run into this? I'm suspecting the problem might be the nvidia-525.85.05 driver. nvidia-525.60.11 was the previously installed version, and that worked fine. I don't think it's libx11 again, since it's a new version, but could be.

I tried running xev to see if that provided any clues, but when xev is running the mouse works perfectly. Maybe that's a clue.

Last edited by pgoetz (2023-04-03 20:35:35)

seth · 2023-01-27 09:34:16

Do you get the same behavior in an openbox session?
When the cursor unfreezes, does it jump to catch up w/ the intermittent movements or does it pick up where it froze?

V1del · 2023-01-27 09:53:56

Is it just the mouse? I have general occasional "freezes" (videos/games will stutter for a bit) since the 6.1 kernels that I haven't gotten to investigate more deeply

pgoetz · 2023-01-27 11:50:27

seth wrote:

Do you get the same behavior in an openbox session?
When the cursor unfreezes, does it jump to catch up w/ the intermittent movements or does it pick up where it froze?

I haven't tried openbox. I probably should set up an alternate DE to help debug issues like this, it's just this system has been extremely stable for years (until recently) and it's my main work driver, so I don't like experimenting with it. When the cursor unfreezes it does not jump but rather picks up where it left off. Also, it's intermittent (apparently except when xev is running).

pgoetz · 2023-01-27 12:36:06

V1del wrote:

Is it just the mouse? I have general occasional "freezes" (videos/games will stutter for a bit) since the 6.1 kernels that I haven't gotten to investigate more deeply

As far as I can tell, it's just the mouse. I don't play real games on this machine, but Gottet (= tetris) when I need a brain break is performing normally; i.e. no stuttering or slow down. Video replay is also dead normal. If anything, launching applications is faster than it was before. I have mitigations=off set in /boot/loader/entries/arch.conf which helps performance considerably.

V1del · 2023-01-27 13:08:51

It's normal here as well until it randomly isn't and it's not frequent enough to be overy bothersome. FWIW other possible culprits, did the update include your first bump to mesa 22.3 ? That enabled GL worker threads by default in a lot of mesa drivers, which lead to a variety of issues similar to that in a bunch of stuff, though this shouldn't affect the nvidia driver, assuming it is your actual driving force and this isn't a laptop in an Optimus configuration.

Last edited by V1del (2023-01-27 13:09:32)

seth · 2023-01-27 13:26:58

When the cursor unfreezes it does not jump but rather picks up where it left off.

Is the mouse wired or wireless?
Do you use some sort of powermanagement daemon?
Try to disable usb autosuspend, https://wiki.archlinux.org/title/Power_ … utosuspend

usbcore.autosuspend=-1

to turn it off globally, but userspace tools may reset this.

You can install and try openbox parallel to mate, but if it's the input signal rather than IO or CPU overload or just the graphics, that's probably moot.

ftr, signal altered between brain and hands

seth almost wrote:

does it jump to catch up w/ the intermediary movements

pgoetz · 2023-01-27 13:42:24

V1del wrote:

It's normal here as well until it randomly isn't and it's not frequent enough to be overly bothersome. FWIW other possible culprits, did the update include your first bump to mesa 22.3 ?

It's definitely not normal for me. I generally get great performance from what was high end but now 9-year-old desktop hardware. Just checked the pacman pkg cache, and this is my first bump to mesa 22.3. Argh, so many variables here it's super frustrating to just think of how to debug. Right now I'm trying to figure out how to find the DKMS nvidia driver I want to downgrade to in the Archive. Nvidia is still my main suspect at the moment.

pgoetz · 2023-01-27 13:46:55

seth wrote:

Do you use some sort of powermanagement daemon?
Try to disable usb autosuspend, https://wiki.archlinux.org/title/Power_ … utosuspend
usbcore.autosuspend=-1
to turn it off globally, but userspace tools may reset this.

The mouse is wireless (you reminded me to try plugging a wired mouse to see if this makes a difference), but no power management daemon. This is an always on desktop that I remote into regularly from the office.

I'm nearly 100% sure it's unrelated to usb autosuspend. The problem generally occurs in the middle of mouse movement, which would mean the daemon is suspending an in use USB device.

seth · 2023-01-27 14:12:12

No difference w/ the wired mouse?
If you suspect the nvidia driver and the problem doesn't affect other video output, you can try

Section "Device"
    Identifier "Default nvidia Device"
    Driver      "nvidia"
    Option      "SWCursor"              "True"
EndSection

pgoetz · 2023-01-27 14:14:04

Update: It looks like the problem was the wireless mouse (Logitech M510). I just plugged in an old Microsoft wired USB mouse, and while I had to bump the mouse acceleration from around 30% to max to get close to the previous performance, the stuttering problem appears to have gone away entirely. When I'm not swamped with a work deadline I'll try a new Logitech M510 which I have lying around. The wired mouse is so much slower than the M510 that the stuttering could have gone away just because there are fewer mouse interrupt events to process. If I connect a brand new M510, that will resolve that question. I made sure to use exactly the same USB port in order to eliminate that as a possibility.

I know from long experience that the Logitech wireless mice will inexplicably start doing weird things and then need to be replaced (last time the middle mouse button click turned intermittent, which is unbearable for an X windows user), and that could be the case here; it's just inconceivably suspicious that a mouse hardware issue would manifest itself exactly after running updates and rebooting. I can live with a slower mouse vs. the stutter thing though.

Thanks for everyone's help with this. I really appreciate it. I'm not going to mark this as resolved yet because it could still be a software issue involving interrupt processing which I won't be able to determine until I switch mice again. That would be useful information if true.

Also, thanks Seth for the suggestion to try a wired mouse. I had planned to try this but then got lost in the fog of figuring out how to find things in the Arch archive. This could use a good search engine. As far as I can tell, you can't search it at all using Google.

Last edited by pgoetz (2023-01-27 14:15:44)

V1del · 2023-01-27 14:31:24

Logitech mice have known current kernel issues with a potential high res wheel enablement they might be doing, most noticable should be the wheel, but the way these things react might get to some weird fuckery with the higher number of events to process. As a test can you check whether hid-logitech-hidpp is loaded with your wireless mouse? If it is, try blacklisting it and unloading it's module and then reconnecting the faulty mouse.

pgoetz · 2023-02-11 22:55:40

V1del wrote:

As a test can you check whether hid-logitech-hidpp is loaded with your wireless mouse? If it is, try blacklisting it and unloading it's module and then reconnecting the faulty mouse.

This seemed like a promising hypothesis, but blacklisting the hid_logitech_hidpp didn't resolve the intermittent stuttering, and when I have a wired mouse plugged in at the same time, the mouse seems to stop working entirely when the module is blacklisted. I tried blacklisting hid_logitech_dj as well, which also didn't help. Same result when blacklisting just one or the other of these modules.

Last edited by pgoetz (2023-02-11 22:56:03)

pgoetz · 2023-02-11 23:22:09

Updated the system on 2023-02-11 to see if this was just some software issue that got resolved, but the mouse stutter (or not working at all) persists. I tried a brand new Logitech M510 plugged into a different USB port with the same result, so it's definitely not a hardware issue. Also, the old M510 works great connected to an HP laptop running Ubuntu 22.10. I also checked /lib/udev/rules.d/70-mouse.rules to see if there might be a clue there, but this is just a generic udev rule set. Sadly I'm going to have to leave this issue unresolved for now.

seth · 2023-02-12 07:04:07

Is the lts kernel affected?

pgoetz · 2023-02-18 20:25:26

seth wrote:

Is the lts kernel affected?

I planned to test this, but never got there. I duplicated my workstation install on a laptop I have, and with the 6.1.12 kernel, the problem doesn't exist on the laptop, using the same M510 mouse I had previously on the workstation. So this is clearly not an issue with the new linux kernel and the logitech modules (or at least not just the new kernel and logitech modules). I checked to make sure those modules were loaded on the laptop. I upgraded the workstation to 6.1.12, and unfortunately the problem persists. The laptop has a 12th gen i7 processor and my workstation has a 4th generation i7-4790S. On the other hand, the clock speed of my workstation CPU is 3.2GHz, which is higher than the on the laptop and in any case this is independent of processor load. The mouse fails to work correctly even when nothing is running and works fine on the laptop with a lot of stuff running. Don't think it's an issue of the CPU getting overloaded with interrupts.

The laptop is just has intel graphics. The workstation has a cheap Nvidia card, so is using the Nvidia proprietary drivers. Both are running with xorg-server-xvfb, so I'm back to suspecting the Nvidia drivers, since that's the only notable difference between the machines i can think of. I use this machine for work, so don't want to fiddle with it too much, but the next step would be to test with the nouveau driver, as I can't think of what else would be causing this.

seth · 2023-02-18 22:14:53

If nouveau doesn't get you ahead:
1. check the layer where this occurs (evtest, libinput debug-events, xev -event mouse)
2. eliminate radio interference (2.4GHz wifi, bluetooth - perhaps try a usb slot on the other end of the hardware)

pgoetz · 2023-02-19 19:03:57

Thanks for the ongoing suggestions. I already tried moving the USB receiver to the front of the machine; that didn't help. Also keep in mind that this has worked perfectly for years; one would assume the radio interference wouldn't change if the hardware doesn't change. Meanwhile, I duplicated the installation on another workstation with similar hardware, save this one has a cheap AMD graphics card rather than Nvidia, and again, no problems with the M510 wireless mouse on that machine.

pgoetz · 2023-02-19 19:18:58

The odd thing about this issue is that when I run

libinput debug-events

the problem seems to go away completely (although it might take 15 seconds before it goes away). If I kill the libinput process the mouse continues to work for some number of seconds and then starts to flake out again intermittently.

seth · 2023-02-19 19:52:02

Does the mouse stall if you simply run glxgears (or a movie or anything that keeps the display busy)?

pgoetz · 2023-02-20 18:37:48

seth wrote:

Does the mouse stall if you simply run glxgears (or a movie or anything that keeps the display busy)?

I think that's the "USB device goes to sleep prematurely" hypothesis. The answer is I tried doing the libinput debug-events trick again first, and this time the mouse wouldn't budge. However, I think I solved the problem.

Not sure why this didn't occur to me to try earlier, but I moved the mouse receiver to a USB3 port (this is an old machine), and now the Logitech M510 wireless mouse is working perfectly again. The other machines I've been testing on only have USB3 ports, which explains why I never saw the problem there. So something changed in the kernel which will no longer allow wireless mice (I only tested 2) to work properly when connected to USB2 ports. Makes sense they would start deprecating this stuff.

Thanks for everyone's help and I'm going to mark this as solved; maybe someone else will benefit from this observation.

seth · 2023-02-20 22:33:19

I think that's the "USB device goes to sleep prematurely" hypothesis.

No, the hypothesis would have been that the cursor isn't udpated on screen.

Ftr:

Makes sense they would start deprecating this stuff.

seth wrote:

Is the lts kernel affected?

Edit: fuck

I'd doubt there's a "usb 2 is old tech, so let's break it" sentiment.

A kernel regression needs to be fixed, but other explanations would be:
a) power saving / auto-suspend
b) the particular bus does not longer provide enough voltage/current to supply the dongle
c) ehci/xhci buffer jam, check the system journal and see https://wiki.archlinux.org/title/Mouse_polling_rate

Last edited by seth (2023-02-20 22:35:03)

pgoetz · 2023-03-01 17:58:58

seth wrote:

I'd doubt there's a "usb 2 is old tech, so let's break it" sentiment.
A kernel regression needs to be fixed, but other explanations would be:
a) power saving / auto-suspend
b) the particular bus does not longer provide enough voltage/current to supply the dongle
c) ehci/xhci buffer jam, check the system journal and see https://wiki.archlinux.org/title/Mouse_polling_rate

Regarding your first comment; no, of course not, this isn't what I meant. I need to find another machine with USB2 ports that I can test on, as I don't have the cycles to experiment on my main workstation, and my other workstation and laptop only have USB3 ports (or higher).

Running through your hypothesis list, nearly 100% sure it's not a), as it's a plugged in midtower with little power savings implemented, and I looked for this based on an earlier suggestion. Regarding b), the probability of the voltage on that USB bus suddenly dying exactly after I upgraded the OS seems unlikely. Other stuff I plug in to those ports (albeit mostly USB sticks) seem to work fine. I'd like to follow up on c) because I agree this is probably some kind of regression, but need to identify a machine to test on which is not the machine I use for work which has 20 terminals etc. open on it all the time, frequently doing stuff.

Last edited by pgoetz (2023-03-01 18:24:22)

pgoetz · 2023-04-03 20:43:14

I removed the SOLVED from this post. The switch to a USB3 port improved but the problem, but it appears to be happening again, albeit considerably more intermittently. Since I've only experienced this issue on my main workstation (and use the same or similar mouse on at least 3 other machines) I'm starting to think it is an issue with my USB bus. The machine is now 9 years old, so it's not beyond the pale. Leaving the issue open just in case.

seth · 2023-04-04 07:35:07

Does the mouse work properly on a different SW stack (live distro, eg. grml or knoppix)?

Arch Linux

#1 2023-01-27 00:40:20

After 2023-01-26 update, mouse is intermittently laggy

#2 2023-01-27 09:34:16

Re: After 2023-01-26 update, mouse is intermittently laggy

#3 2023-01-27 09:53:56

Re: After 2023-01-26 update, mouse is intermittently laggy

#4 2023-01-27 11:50:27

Re: After 2023-01-26 update, mouse is intermittently laggy

#5 2023-01-27 12:36:06

Re: After 2023-01-26 update, mouse is intermittently laggy

#6 2023-01-27 13:08:51

Re: After 2023-01-26 update, mouse is intermittently laggy

#7 2023-01-27 13:26:58

Re: After 2023-01-26 update, mouse is intermittently laggy

#8 2023-01-27 13:42:24

Re: After 2023-01-26 update, mouse is intermittently laggy

#9 2023-01-27 13:46:55

Re: After 2023-01-26 update, mouse is intermittently laggy

#10 2023-01-27 14:12:12

Re: After 2023-01-26 update, mouse is intermittently laggy

#11 2023-01-27 14:14:04

Re: After 2023-01-26 update, mouse is intermittently laggy

#12 2023-01-27 14:31:24

Re: After 2023-01-26 update, mouse is intermittently laggy

#13 2023-02-11 22:55:40

Re: After 2023-01-26 update, mouse is intermittently laggy

#14 2023-02-11 23:22:09

Re: After 2023-01-26 update, mouse is intermittently laggy

#15 2023-02-12 07:04:07

Re: After 2023-01-26 update, mouse is intermittently laggy

#16 2023-02-18 20:25:26

Re: After 2023-01-26 update, mouse is intermittently laggy

#17 2023-02-18 22:14:53

Re: After 2023-01-26 update, mouse is intermittently laggy

#18 2023-02-19 19:03:57

Re: After 2023-01-26 update, mouse is intermittently laggy

#19 2023-02-19 19:18:58

Re: After 2023-01-26 update, mouse is intermittently laggy

#20 2023-02-19 19:52:02

Re: After 2023-01-26 update, mouse is intermittently laggy

#21 2023-02-20 18:37:48

Re: After 2023-01-26 update, mouse is intermittently laggy

#22 2023-02-20 22:33:19

Re: After 2023-01-26 update, mouse is intermittently laggy

#23 2023-03-01 17:58:58

Re: After 2023-01-26 update, mouse is intermittently laggy

#24 2023-04-03 20:43:14

Re: After 2023-01-26 update, mouse is intermittently laggy

#25 2023-04-04 07:35:07

Re: After 2023-01-26 update, mouse is intermittently laggy

Board footer