Mouse randomly freezes for a short time

DarkShadow44 · 2021-06-28 16:01:46

Since a while ago (not how sure how long exactly, 2-3 weeks) my mouse pointer freezes from time to time, and then jumps to where it should have been. The freeze itself lasts only short, up to a half second at most.

Not sure what causes this, and not even how to analyse. It's sporadic, so hard to reproduce on demand. It's often enough to be really annoying though. Any clues on how to start investigating?

Some notes:
- It works just fine in win10, so probably not a hardware issue.
- It appears on KDE Plasma X11, KDE Plasma Wayland and XFCE. So probably not relevant to the DE.
- It worked fine in the past, though I can't tell what changed. There's been a lot of updates...
- I read about another issue with the video freezing from time to time on AMD hardware, although youtube definitely doesn't freeze when the cursor does.

System:
- AMD RX 5700
- CPU AMD Ryzen 7 3800
- Linux 5.12.12 (5.12.13.arch1-2 doesn't work either, currently has the "GPU at 100% bug", that's why the old kernel)
- dmesg doesn't show anything when the freeze occurs

Last edited by DarkShadow44 (2021-06-28 16:02:32)

xerxes_ · 2021-06-28 19:12:45

But what is the model of that mouse (post output of lsusb)?

Ropid · 2021-06-29 04:20:31

Maybe it's the system starting to use swap? With the default vm.swappiness=60, the system likes to start putting things into swap after around half of RAM is used.

tucuxi · 2021-06-29 05:30:08

journalctl -b

seth · 2021-06-29 05:48:45

With the default vm.swappiness=60, the system likes to start putting things into swap after around half of RAM is used.

No.
https://bbs.archlinux.org/viewtopic.php?id=231265

Could be usb suspend, BT suspend, BT/WiFi interference, CPU spike, OOM and because of "works just fine in win10" and in general: 3rd link below

xerxes_ wrote:

But what is the model of that mouse (post output of lsusb)?

Ropid · 2021-06-29 15:14:16

seth wrote:

With the default vm.swappiness=60, the system likes to start putting things into swap after around half of RAM is used.
No.
https://bbs.archlinux.org/viewtopic.php?id=231265

No? I wrote "around half of RAM" because that's what I saw happening here. The PC had 8GB RAM and I saw the system swapping after about 4GB was "used" in the 'free' output.

seth · 2021-06-29 15:24:26

It's more complicated than that, but in general: no. Read the linked thread.
You'll use SWAP if you have it, if you need it (ie. you run "OOM", that's more complicated as well because RAM is systematically overcomitted) and the system cannot or, because of the swappiness, does not opt to evict file backed memory. A process can trigger this by allocating lots of memory (forcing the kernel to chose between SWAP and cache drops) and then just releasing it. Since the swap isn't read back into RAM for no reason nor dropped until its invalidated, you might end in a state that *looks* as if the system is using SWAP despite plenty of RAM being available. But short of a kernel bug, that's notwhat's happening.

If you can replicate the situation, feel free to open a thread so we can look at it. It's OT here and I just replied because specific myths about vm.swappiness are constantly repeated on the interwebz and become truthiness.

DarkShadow44 · 2021-06-29 16:17:15

Thank you for your replies!

xerxes_ wrote:

But what is the model of that mouse (post output of lsusb)?

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 006: ID 0d8c:0014 C-Media Electronics, Inc. Audio Adapter (Unitek Y-247A)
Bus 003 Device 007: ID 0e8f:0012 GreenAsia Inc. Joystick/Gamepad
Bus 003 Device 005: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 003 Device 004: ID 04d9:a067 Holtek Semiconductor, Inc. USB Gaming Mouse           <------------
Bus 003 Device 003: ID 046d:c31c Logitech, Inc. Keyboard K120
Bus 003 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 1bcf:28c4 Sunplus Innovation Technology Inc. FHD Camera Microphone
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Ropid wrote:

Maybe it's the system starting to use swap?

I don't have any swap, I disabled that. I have 32 GB of ram, and usually 4 GB used.

tucuxi wrote:

journalctl -b

There is no new entries when those freezes occur. Or do you think the complete log could still be useful?

EDIT: I should add that usually my mouse is attached via a KVM switch. I'll test if that makes a difference...

Last edited by DarkShadow44 (2021-06-29 16:23:28)

DarkShadow44 · 2024-04-23 18:50:54

Still an issue, although it seems to come and go which makes pinning it down a real nightmare. Any ideas?

xerxes_ · 2024-04-25 10:12:44

Post full output of commands:

lsusb -vd 04d9:a067
sudo journalctl -b

DarkShadow44 · 2024-04-25 14:36:57

lsusb: https://pastebin.com/Y1cWP4Vr

Journal: https://gist.github.com/DarkShadow44/43 … 875f03b337

There is no new entries in the journal when the stutter happens (I made sure to reproduce shortly before taking the log), and stopping earlyoom doesn't change things either.

Last edited by DarkShadow44 (2024-04-25 14:39:42)

seth · 2024-04-25 15:18:06

It's 28k lines, the vast majority of it (23k lines) earlyoom spam.
You might want to share the raw file because it sucks to open that in a browser.

https://gist.githubusercontent.com/Dark … /mouse.log

Device is

Apr 25 05:15:50 arch kernel: usb 1-8.3: New USB device found, idVendor=04d9, idProduct=a067, bcdDevice= 1.06
Apr 25 05:15:53 arch kernel: input: Holtek USB Gaming Mouse as /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-8/1-8.3/1-8.3:1.0/0003:04D9:A067.0004/input/input21
Apr 25 05:15:53 arch kernel: holtek_mouse 0003:04D9:A067.0004: input,hidraw3: USB HID v1.10 Keyboard [Holtek USB Gaming Mouse] on usb-0000:03:00.0-8.3/input0
Apr 25 05:15:53 arch kernel: holtek_mouse 0003:04D9:A067.0005: Fixing up report descriptor
Apr 25 05:15:53 arch kernel: input: Holtek USB Gaming Mouse as /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-8/1-8.3/1-8.3:1.1/0003:04D9:A067.0005/input/input23
Apr 25 05:15:53 arch kernel: holtek_mouse 0003:04D9:A067.0005: input,hiddev96,hidraw5: USB HID v1.10 Mouse [Holtek USB Gaming Mouse] on usb-0000:03:00.0-8.3/input1
Apr 25 05:15:53 arch kernel: holtek_mouse 0003:04D9:A067.0006: hiddev97,hidraw6: USB HID v1.10 Device [Holtek USB Gaming Mouse] on usb-0000:03:00.0-8.3/input2

It resets once

Apr 25 15:53:08 arch kernel: usb 1-8.3: reset full-speed USB device number 6 using xhci_hcd

but that's in response to

Apr 25 10:57:36 arch kernel: PM: suspend entry (deep)

Apr 25 05:15:53 arch kernel: input: GreenAsia Inc.      USB  Joystick   as /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-8/1-8.1/1-8.1.3/1-8.1.3:1.0/0003:0E8F:0012.0007/input/input22

Is this the mouse or an aditional joystick on the same bus?

Since the mouse comes w/ it's own kernel module, does this ever happen with a $5 office supply rodent?
Try to disable https://wiki.archlinux.org/title/Power_ … utosuspend
"usbcore.autosuspend=-1" should™ do that globally.

DarkShadow44 · 2024-04-25 16:30:31

New kernel log: https://pastebin.com/Gs6MBQA0

The power setting didn't change anything. The reset was probably due to hibernation. The new log is cleaner, just rebooted.

That second device (GreenAsia Inc. USB Joystick) is a gamepad. I unplugged it before restarting, same results.

Where do you see that the mouse has its own kernel module? With "lsusb -t" I only see "usbhid". Sadly I don't have another mouse for testing, apart from one that has the same brand, but I don't think that would help, would it?

I forgot to mention that my mouse is on a USB-hub, which in turn is connected to a KVM-switch, for dual use with two PCs.
I did some more testing, and I could only reproduce the issue when the mouse was connected to the Hub or the KVM-switch not when connected to the PC directly. But seeing how fickle this issue is (reproduction rate about 1/6) that could be a fluke.
I'll report back in a few days if that makes any difference. If only the issue was easy to reproduce...

Last edited by DarkShadow44 (2024-04-25 16:34:57)

seth · 2024-04-25 17:08:06

Where do you see that the mouse has its own kernel module?

kernel: holtek_mouse
modinfo hid_holtek_mouse

I forgot to mention that my mouse is on a USB-hub, which in turn is connected to a KVM-switch, for dual use with two PCs.

https://www.google.com/search?q=kvm%20s … e%20freeze

DarkShadow44 · 2024-04-26 07:26:30

I can rule out the KVM-switch, today I managed to reproduce the lag while having the mouse connected directly to the PC.

I tried blacklisting that kernel module in hope it would fall back to a generic hid module, but that is not the case - it only results not having a mouse at all.
Upside is that I managed to borrow another mouse, I'll test if that has the same issues.

Arch Linux

#1 2021-06-28 16:01:46

Mouse randomly freezes for a short time

#2 2021-06-28 19:12:45

Re: Mouse randomly freezes for a short time

#3 2021-06-29 04:20:31

Re: Mouse randomly freezes for a short time

#4 2021-06-29 05:30:08

Re: Mouse randomly freezes for a short time

#5 2021-06-29 05:48:45

Re: Mouse randomly freezes for a short time

#6 2021-06-29 15:14:16

Re: Mouse randomly freezes for a short time

#7 2021-06-29 15:24:26

Re: Mouse randomly freezes for a short time

#8 2021-06-29 16:17:15

Re: Mouse randomly freezes for a short time

#9 2024-04-23 18:50:54

Re: Mouse randomly freezes for a short time

#10 2024-04-25 10:12:44

Re: Mouse randomly freezes for a short time

#11 2024-04-25 14:36:57

Re: Mouse randomly freezes for a short time

#12 2024-04-25 15:18:06

Re: Mouse randomly freezes for a short time

#13 2024-04-25 16:30:31

Re: Mouse randomly freezes for a short time

#14 2024-04-25 17:08:06

Re: Mouse randomly freezes for a short time

#15 2024-04-26 07:26:30

Re: Mouse randomly freezes for a short time

Board footer