[postponed, currently not reproducible]Wireless mouse randomly dis....

zoltan · 2023-12-14 20:19:49

Wireless mouse randomly disconnects and won't reconnect until reboot

I've tried searching for solutions to this problem, but other posts are either referring to mice that will randomly disconnect and reconnect multiple times during a session, or mice that are just completely undetected. What has been happening with mine (I have the same issue with two different mice that I use) is they will completely disconnect and never reconnect. I'll be mid mouse stroke and the cursor will just suddenly stop moving. Absolutely nothing will make the mouse reconnect. Unplug and replug the dongle? Nope. Turn the mouse off and back on using the power switch on the mouse? Nope. Move the dongle to a different USB port? Nope. Log out and log back in? Nope. Is the battery dying? Nope. This happens on both mice with full battery. Literally the only thing that will get the mouse to reconnect is a reboot. I even tried updating my BIOS per one suggestion I was given, as the BIOS has apparently "been known to cause bugs". I've been searching for an answer to this for weeks and haven't been able to find anything that solves my issue. I need help finding a solution, because mice have become all but unusable on my laptop. Having to reboot every time my mouse stops working is a real pain in the ass, so I've basically just been using my mouse for as long as I can until it stops working, and then just continue without a mouse until it's convenient for me to reboot.

I'm not sure it's a driver problem because it's the exact same problem with two different mice from two different manufacturers. Also, if it were a driver issue, I would expect the issue to be at least relatively common and not so difficult to find a solution. Furthermore, both mice work flawlessly when they are working. No scrolling or clicking problems. No cursor tracking problems. All buttons work as they should. Everything works exactly as it should...with just the one caveat that they randomly disconnect for no apparent reason. I have no idea what causes it. I've been completely unable to reproduce the issue at will.

I did find something in the logs that could be telling me what the problem is.

Dec 14 11:11:45 arch kernel: usb 2-3: device not accepting address 2, error -108
Dec 14 11:11:46 arch kernel: usb 2-3: device not accepting address 2, error -108
Dec 14 11:11:47 arch kernel: usb 2-3: device not accepting address 2, error -108
Dec 14 11:11:48 arch kernel: usb 2-3: device not accepting address 2, error -108
Dec 14 11:11:48 arch kernel: usb 2-3: USB disconnect, device number 2
Dec 14 11:11:48 arch multipath[3625]: sysfs_is_multipathed: error scanning /sys/block/sdb/holders
Dec 14 11:11:48 arch kernel: usb usb2-port3: couldn't allocate usb_device

I'm not sure what these kernel and multipath errors mean, but it kinda sounds like something is happening that's causing the kernel to just stop recognizing the dongle. Idk, I don't know where to look. I don't know if this is a mouse firmware problem, a USB firmware problem, a kernel problem, or something else entirely. This issue is relatively new for me as well. I've only been having this problem for maybe the last couple of months. I couldn't say if this began after a specific update. I didn't update and then pay attention for my mouse to stop working. lol. I just noticed one time that my mouse stopped working.

Idk if this will help, but something that I found in another post here was to show the output of lsusb and lspci | grep -i usb, so here are the outputs for both of those:

lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 046d:c53f Logitech, Inc. USB Receiver
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter
Bus 003 Device 003: ID 04f2:b6d9 Chicony Electronics Co., Ltd Integrated Camera
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

lspci | grep -i usb
04:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Raven USB 3.1
04:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Raven USB 3.1

I'm having this issue on a Lenovo ThinkPad E595. The two mice in question that I'm currently using are a SteelSeries Prime Wireless and a Logitech G305. I'm not sure what other specs or information will be necessary. Tell me what you need to know, and I'll tell you. I'm still reading through some other posts I've found here in the forums, as well as some articles on the Wiki about mice and USB ports. The scope of these searches is pretty broad, so I imagine reading through all of this stuff will take quite some time. Any help will be greatly appreciated. I need to fix this problem. It's been driving me insane...

Last edited by zoltan (2023-12-25 16:44:59)

seth · 2023-12-14 22:00:04

1. Is there a parallel windows installation?
2. Do you use sth. like TLP
3. Disable https://wiki.archlinux.org/title/Power_ … utosuspend
4. Can you run the mouse via BT?

108 is ESHUTDOWN "Cannot send after transport endpoint shutdown"

zoltan · 2023-12-14 22:38:30

seth wrote:

1. Is there a parallel windows installation?
2. Do you use sth. like TLP
3. Disable https://wiki.archlinux.org/title/Power_ … utosuspend
4. Can you run the mouse via BT?
108 is ESHUTDOWN "Cannot send after transport endpoint shutdown"

1. No parallel Windows installation. The only OS I currently have installed in Arch Linux.

2. I have TLP installed. It doesn't seem to be working correctly though. At one point I had my power management set up to stop charging at 70% and resume charging at 50%. I liked how that was set up, but after a reinstall several months ago, I haven't been able to get this feature to work.

3. The wiki says to edit /etc/udev/rules.d/50-usb_power_save.rules, but I don't have that file. Should I create the file and change ATTR{power/control}="auto" to ATTR{power/control}="off"? I do have a file in this directory called 99-steelseries-rival.rules. It was generated by rivalcfg(AUR), and the comments advise to not edit the file, but instead regenerate the file with rivalcfg --update-udev. I should note that the reason I installed rivalcfg in the first place was because I was trying to fix this problem. When the problem persisted, I assumed it may just be a firmware issue with SteelSeries in general. I thought that maybe using a different mouse would solve the problem, so I bought a cheapo Logitech from Best Buy. Sadly, the problem persists with the Logitech mouse as well.

4. No. Neither mouse has BT capability. They will only work through the USB wifi dongle. I think the SteelSeries technically is supposed to work without the dongle if it's directly plugged into the machine. I seem to remember being able to use it that way, but I'm not sure. I should double check that on my Windows laptop (a separate machine, not a parallel installation). In any case, the SteelSeries mouse currently does not work on this laptop (my Arch laptop) without the dongle, even if it's physically plugged into the machine.

Should I post the contents of 99-steelseries-rival.rules relevant to my SteelSeries mouse?

Last edited by zoltan (2023-12-14 22:43:31)

seth · 2023-12-15 08:51:16

For a brief test just add "usbcore.autosuspend=-1" to the https://wiki.archlinux.org/title/Kernel_parameters but nb. that TLP will override this at runtime anyway and should provide a setting to control this as well.

https://wiki.archlinux.org/title/Laptop … ry_control
https://wiki.archlinux.org/title/Tp_sma … ed_laptops

ighea · 2023-12-15 09:23:07

Please try upgrading to the latest 6.6.7 kernel release. It fixes some issues related to USB devices for AMD platform.

zoltan · 2023-12-17 20:48:20

ighea wrote:

Please try upgrading to the latest 6.6.7 kernel release. It fixes some issues related to USB devices for AMD platform.

I'm on 6.6.7. The problem persists. I'm going to give Seth's idea a try and test that out. I'll report back with the results.

zoltan · 2023-12-17 21:10:57

seth wrote:

For a brief test just add "usbcore.autosuspend=-1" to the https://wiki.archlinux.org/title/Kernel_parameters but nb. that TLP will override this at runtime anyway and should provide a setting to control this as well.
https://wiki.archlinux.org/title/Laptop … ry_control
https://wiki.archlinux.org/title/Tp_sma … ed_laptops

Since you said TLP will override this anyway, what I've done for now is 1) ran `sudo tlp usb disable`, and 2) edited /etc/tlp.conf to show `USB_AUTOSUSPEND=0`. If this doesn't work, I'll try disabling TLP altogether and manually edit the suggested kernel parameter to see what happens without TLP interfering with it.

zoltan · 2023-12-19 21:20:41

seth wrote:

For a brief test just add "usbcore.autosuspend=-1" to the https://wiki.archlinux.org/title/Kernel_parameters but nb. that TLP will override this at runtime anyway and should provide a setting to control this as well.
https://wiki.archlinux.org/title/Laptop … ry_control
https://wiki.archlinux.org/title/Tp_sma … ed_laptops

Before I do this, I just want to clarify that I'm doing it correctly. I'm using grub, so if I'm not mistaken I have to add this parameter by editing /etc/default/grub, and then running grub-mkconfig -o /boot/grub/grub.cfg. It sounds like the new parameter needs to be added to `GRUB_CMDLINE_LINUX_DEFAULT=`.

For me, this line currently reads as:

GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet"

After adding this parameter, it should read as:

GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet usbcore.autosustend=-1"

Do I have that correct?

seth · 2023-12-19 21:23:22

You can just select the boot entry in grub when booting, press "e" and temporarily change the commandline there for the test.
Disabling it in TLP didn't help?

zoltan · 2023-12-19 21:35:55

No. Even after making the change in TLP, the problem persists. (Edit: I was able to fix my battery threshold issue though! Woo!)

I wanted to make the change permanent because there are instances where I can make it through a whole day without my mouse disconnecting. That's why I've been taking a couple of days to reply here. I want to allow myself some time to see what kind of behavior patterns arise and/or change over a course of ~24-36 hours. I did just do a fresh reboot and made a temporary change by pressing "e" and adding the parameter that way as you suggested, but I don't want to have to do that each time. In any case, it sounds like I had it right, so I'm gonna go ahead and just edit grub. I can always change it back if I need to. I just wanted to make sure I wasn't going to break something.

I do want to add that I believe this is a usb problem, not a mouse problem. I confirmed that when I experience this problem with my mouse, I also cannot get any external usb storage devices to connect (and connected storage devices will disconnect and become inaccessible). What's strange though is that I can't recall this problem ever occurring when I only have external usb storage connected. I've had all of my usb devices disconnect when I've been using a mouse, but as far as I can recall I've never had any usb devices disconnect when I haven't connected a mouse. This is why I originally thought it was a mouse issue, because it seems to only occur whilst using a mouse. But it does affect all usb ports.

Last edited by zoltan (2023-12-19 21:46:13)

seth · 2023-12-19 21:51:33

I confirmed that when I experience this problem with my mouse, I also cannot get any external usb storage devices to connect

Wowowowow.

That sounds more like the entire bus went south and the mouse is just an obvious indicator of that.
Do you have a journal from a boot where this happened, eg.

sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st

for the previous one?

zoltan · 2023-12-20 02:13:47

I'll have to wait until it happens again. The next time it happens, I'll do it immediately with -0 for the offset.

zoltan · 2023-12-22 21:39:54

I don't have any new updates. Haven't experienced a mouse disconnect in a couple of days. Not sure if the issue has somehow been resolved. I don't want to keep this open forever if the issue doesn't reoccur. Is there a way that I can close this thread? If it happens again, then I can always just open a new thread and link back to this one. Not really sure what I should do here. I don't want to just abandon the thread with no resolution or conclusion. Should I just leave it open and come back if the problem does reoccur?

seth · 2023-12-22 21:46:50

You could mark it as "[postponed, currently not reproducible]" or so.
Deleting the thread and starting over in case will lose some context/pre-established information.

nb. that systemd maintains journals of previous boots and you might actually still have one covering the incident which might at least hint at the cause.

zoltan · 2023-12-22 22:13:43

I'd have to go quite far back. I can't remember exactly when the last boot was before this occurred. I know it was some time earlier this week, but I'm not sure exactly when. For journalctl -b, what would I need to use as the offset parameter to list boots since Sunday?

seth · 2023-12-22 22:18:03

-b takes an index, the smaller the negative number (bigger the digit) the further you move back in time.
But you can also filter by date, https://wiki.archlinux.org/title/System … ing_output & https://man.archlinux.org/man/journalct … NG_OPTIONS
(--since and --until)

zoltan · 2023-12-22 23:12:04

Some of the filters are confusing me cuz I'm a bit of a knuckle dragger (lol), and some of there were giving me some very extraneous output that I don't want to post here to avoid clutter. I did run this, however, and I found something that stands out to me:

# journalctl -b -24 | grep usb
Dec 17 13:44:36 arch kernel: usbcore: registered new interface driver usbfs
Dec 17 13:44:36 arch kernel: usbcore: registered new interface driver hub
Dec 17 13:44:36 arch kernel: usbcore: registered new device driver usb
Dec 17 13:44:36 arch kernel: usbcore: registered new interface driver usbserial_generic
Dec 17 13:44:36 arch kernel: usbserial: USB Serial support registered for generic
Dec 17 13:44:36 arch kernel: usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.06
Dec 17 13:44:36 arch kernel: usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Dec 17 13:44:36 arch kernel: usb usb1: Product: xHCI Host Controller
Dec 17 13:44:36 arch kernel: usb usb1: Manufacturer: Linux 6.6.7-arch1-1 xhci-hcd
Dec 17 13:44:36 arch kernel: usb usb1: SerialNumber: 0000:04:00.3
Dec 17 13:44:36 arch kernel: usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
Dec 17 13:44:36 arch kernel: usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.06
Dec 17 13:44:36 arch kernel: usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Dec 17 13:44:36 arch kernel: usb usb2: Product: xHCI Host Controller
Dec 17 13:44:36 arch kernel: usb usb2: Manufacturer: Linux 6.6.7-arch1-1 xhci-hcd
Dec 17 13:44:36 arch kernel: usb usb2: SerialNumber: 0000:04:00.3
Dec 17 13:44:36 arch kernel: usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.06
Dec 17 13:44:36 arch kernel: usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Dec 17 13:44:36 arch kernel: usb usb3: Product: xHCI Host Controller
Dec 17 13:44:36 arch kernel: usb usb3: Manufacturer: Linux 6.6.7-arch1-1 xhci-hcd
Dec 17 13:44:36 arch kernel: usb usb3: SerialNumber: 0000:04:00.4
Dec 17 13:44:36 arch kernel: usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.
Dec 17 13:44:36 arch kernel: usb usb4: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.06
Dec 17 13:44:36 arch kernel: usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Dec 17 13:44:36 arch kernel: usb usb4: Product: xHCI Host Controller
Dec 17 13:44:36 arch kernel: usb usb4: Manufacturer: Linux 6.6.7-arch1-1 xhci-hcd
Dec 17 13:44:36 arch kernel: usb usb4: SerialNumber: 0000:04:00.4
Dec 17 13:44:36 arch kernel: usb 1-4: new full-speed USB device number 2 using xhci_hcd
Dec 17 13:44:36 arch kernel: usb 3-1: new full-speed USB device number 2 using xhci_hcd
Dec 17 13:44:36 arch kernel: usb 1-4: New USB device found, idVendor=046d, idProduct=c53f, bcdDevice=44.01
Dec 17 13:44:36 arch kernel: usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Dec 17 13:44:36 arch kernel: usb 1-4: Product: USB Receiver
Dec 17 13:44:36 arch kernel: usb 1-4: Manufacturer: Logitech
Dec 17 13:44:36 arch kernel: usb 3-1: New USB device found, idVendor=8087, idProduct=0025, bcdDevice= 0.02
Dec 17 13:44:36 arch kernel: usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Dec 17 13:44:36 arch kernel: input: Logitech USB Receiver as /devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb1/1-4/1-4:1.0/0003:046D:C53F.0001/input/input6
Dec 17 13:44:36 arch kernel: hid-generic 0003:046D:C53F.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:04:00.3-4/input0
Dec 17 13:44:36 arch kernel: input: Logitech USB Receiver Mouse as /devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb1/1-4/1-4:1.1/0003:046D:C53F.0002/input/input7
Dec 17 13:44:36 arch kernel: input: Logitech USB Receiver Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb1/1-4/1-4:1.1/0003:046D:C53F.0002/input/input8
Dec 17 13:44:36 arch kernel: usb 3-2: new high-speed USB device number 3 using xhci_hcd
Dec 17 13:44:36 arch kernel: input: Logitech USB Receiver System Control as /devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb1/1-4/1-4:1.1/0003:046D:C53F.0002/input/input9
Dec 17 13:44:36 arch kernel: hid-generic 0003:046D:C53F.0002: input,hiddev96,hidraw1: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:04:00.3-4/input1
Dec 17 13:44:36 arch kernel: hid-generic 0003:046D:C53F.0003: hiddev97,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:04:00.3-4/input2
Dec 17 13:44:36 arch kernel: usbcore: registered new interface driver usbhid
Dec 17 13:44:36 arch kernel: usbhid: USB HID core driver
Dec 17 13:44:36 arch kernel: usb 3-2: New USB device found, idVendor=04f2, idProduct=b6d9, bcdDevice=26.99
Dec 17 13:44:36 arch kernel: usb 3-2: New USB device strings: Mfr=3, Product=1, SerialNumber=2
Dec 17 13:44:36 arch kernel: usb 3-2: Product: Integrated Camera
Dec 17 13:44:36 arch kernel: usb 3-2: Manufacturer: Chicony Electronics Co.,Ltd.
Dec 17 13:44:36 arch kernel: usb 3-2: SerialNumber: 0001
Dec 17 13:44:36 arch kernel: logitech-djreceiver 0003:046D:C53F.0001: hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:04:00.3-4/input0
Dec 17 13:44:36 arch kernel: logitech-djreceiver 0003:046D:C53F.0002: hiddev96,hidraw1: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:04:00.3-4/input1
Dec 17 13:44:36 arch kernel: logitech-djreceiver 0003:046D:C53F.0003: hiddev97,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:04:00.3-4/input2
Dec 17 13:44:36 arch kernel: input: Logitech Wireless Mouse PID:4074 Keyboard as /devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb1/1-4/1-4:1.2/0003:046D:C53F.0003/0003:046D:4074.0004/input/input11
Dec 17 13:44:36 arch kernel: input: Logitech Wireless Mouse PID:4074 Mouse as /devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb1/1-4/1-4:1.2/0003:046D:C53F.0003/0003:046D:4074.0004/input/input12
Dec 17 13:44:36 arch kernel: hid-generic 0003:046D:4074.0004: input,hidraw3: USB HID v1.11 Keyboard [Logitech Wireless Mouse PID:4074] on usb-0000:04:00.3-4/input2:1
Dec 17 13:44:36 arch kernel: input: Logitech G305 as /devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb1/1-4/1-4:1.2/0003:046D:C53F.0003/0003:046D:4074.0004/input/input16
Dec 17 13:44:36 arch kernel: logitech-hidpp-device 0003:046D:4074.0004: input,hidraw3: USB HID v1.11 Keyboard [Logitech G305] on usb-0000:04:00.3-4/input2:1
Dec 17 13:44:41 arch kernel: usb 3-2: Found UVC 1.10 device Integrated Camera (04f2:b6d9)
Dec 17 13:44:41 arch kernel: usbcore: registered new interface driver uvcvideo
Dec 17 13:44:41 arch kernel: usbcore: registered new interface driver btusb
Dec 17 13:53:38 arch dbus-daemon[1476]: [system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.home1.service' requested by ':1.73' (uid=0 pid=3996 comm="sudo tlp usb disable")
Dec 17 13:53:42 arch sudo[3996]:   zoltan : TTY=pts/1 ; PWD=/home/zoltan ; USER=root ; COMMAND=/usr/bin/tlp usb disable

On the second to last line, I noticed

Dec 17 13:53:38 arch dbus-daemon[1476]: [system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.home1.service' requested by ':1.73' (uid=0 pid=3996 comm="sudo tlp usb disable")

Incidentally, I've noticed that after disabling TLP and the usbcore.autosuspend module, I didn't notice an immediate change. However, after booting once or twice after making those changes, I haven't noticed the problem.

I have some stuff I need to do this evening, so I don't know if I'll have time to keep looking through the logs tonight. I'll have another look tomorrow afternoon at the very latest. I'll play around with the different filters as well so I can parse out as much useful info as possible. If I post any output that is longer than what I posted here, I'll use the command that you shared above to pipe it through curl to avoid cluttering the thread.

seth · 2023-12-23 08:09:55

I have some stuff I need to do this evening

We all do

If you need others to go though the journal you'll have to post it all b/c the grep removes all context and the events there mostly look like they're simply taking place during the normal boot phase.
However

I've noticed that after disabling TLP and the usbcore.autosuspend module, I didn't notice an immediate change. However, after booting once or twice

sounds like it's just autosuspend (in particular the "once" part…) in which case you may want to limit the change to only exclude the mouse/dongle.

zoltan · 2023-12-25 16:36:57

Ok, so now I'm even more confused. I don't think changing the kernel parameters did anything because I misspelled them. I have "usbcore.autosustend=-1"... Idk, maybe the issue got fixed in a recent update. I know the kernel just updated to 6.6.8, which I'm currently using.

I'll wait and see if it happens again and immediately grab the log for that session when it happens. But for now I'm gonna go ahead and mark the thread as "[postponed, currently not reproducible]" as you previously suggested. I'll try changing the kernel params to include only the mouse and dongle, but I'll have to figure out how to do that first. I'll also try removing the autosuspend parameter altogether and see if the issue returns. If I can at least reproduce the actual problem, maybe we can find a solid solution to it.

In case someone wants to look through everything, here are the logs since Dec 17. I tried passing --until to limit it to the 23rd, but it didn't work. It's only two more days this way anyway. If someone wants more, let me know and I'll push the date farther back. Out of curiosity, what kind of things should I be looking for in the logs? I want to inspect them myself, but there's a freakin lot to read through. Also not really fair to ask other people to read the logs if I'm not at least going to attempt to read them. What are some keywords that I should specifically look for?

Thanks so much for your time and help so far. I hope you're having a Merry Christmas/Holiday season!

seth · 2023-12-25 20:57:07

6.6.8 fixed a massive wifi error in 6.6.7, on a lim it might have been radio interference because of that.
You could downgrade to 6.6.7 and wether the issue returns as consequence.

zoltan · 2023-12-29 02:40:10

Ok, so it just happened again a few minutes ago (around 18:50-ish). I just ran:

sudo journalctl -b -0 | curl -F 'file=@-' 0x0.st

Here is log.

Same usual symptoms. Mouse and other connected usb devices have disconnected. At the time of this event, I was sitting relatively idle with only a few applications open and each running in separate workspaces. Alacritty in one workspace, Firefox in another, Thunderbird in a 3rd, and Virtual Machine Manager and Nemo in a 4th and 5th workspace respectively. No files were actively being transferred or downloaded at this time, and I had no virtual machines open or running. Thunderbird and Alacritty just sit there and do what they do (nothing was actively running in Alacritty). Firefox had several tabs open to various pages on the Debian website. I had just finished downloading some installation images and was verifying them. I paused for a moment to watch a video on my phone, and when I came back to my laptop and tried to move my mouse...well...you know the story.

What I want to illustrate here is that I wasn't doing any particular thing that may have caused this to happen. It happened while I was mostly idle, effectively afk, amidst performing an activity that I haven't done in months (aside from literally just using Firefox...).

As I'm typing this line, I've just noticed that this also seems to include my charger, which connects via usb type-c. I'm gonna do some quick troubleshooting as I continue to type this comment before I reboot. I have not yet unplugged and replugged anything, nor have I rebooted.

As I'm typing this line, I have unplugged and replugged my usb flash drive. Not detected. Next will be my charger.

As I'm typing this line, I have unplugged and replugged my type-c charger, and it has been detected and resumed charging my laptop.

As I'm typing this line, just for shits and giggles I tried unplugging and replugging my mouse dongle. As expected, it did not reconnect.

I haven't taken any time to troubleshoot or mess around with this issue since my last activity on this thread. The issue seemed to have gone away, and although I have been planning on attempting to reproduce the issue, I've had other things on my mind that took my attention more immediately. I mention this because it might be important to know that I have not fiddled with this at all for the last 3 days. I've changed nothing, I've just gone on using my laptop mostly as normal, but I still have the same kernel parameter set, and I still have TLP disabled (there's actually a message about that earlier on in the log I've shared).

Last edited by zoltan (2023-12-29 02:42:30)

seth · 2023-12-29 13:49:05

The charger will likely only draw power and doesn't rely on the actual USB

The last signals of USB

Dec 28 18:05:43 arch kernel: usb 2-3: new SuperSpeed USB device number 2 using xhci_hcd
Dec 28 18:05:43 arch kernel: usb 2-3: New USB device found, idVendor=0781, idProduct=5583, bcdDevice= 1.00
Dec 28 18:05:43 arch kernel: usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec 28 18:05:43 arch kernel: usb 2-3: Product:  SanDisk 3.2Gen1
Dec 28 18:05:43 arch kernel: usb 2-3: Manufacturer:  USB
Dec 28 18:05:43 arch kernel: usb 2-3: SerialNumber: 04011cad45bbcda85d7f074bf84e969b534785f536630573a11e6fd26d879e3e065000000000000000000000c01ba0b2ff1c6d18835581072e2e6382
Dec 28 18:05:43 arch kernel: usb-storage 2-3:1.0: USB Mass Storage device detected
Dec 28 18:05:43 arch kernel: scsi host1: usb-storage 2-3:1.0
Dec 28 18:05:43 arch kernel: usbcore: registered new interface driver usb-storage
Dec 28 18:05:43 arch kernel: usbcore: registered new interface driver uas
Dec 28 18:05:44 arch kernel: scsi 1:0:0:0: Direct-Access      USB      SanDisk 3.2Gen1 1.00 PQ: 0 ANSI: 6
…
Dec 28 18:45:37 arch kernel: usb 2-3: device not accepting address 2, error -108
Dec 28 18:45:37 arch kernel: usb 2-3: device not accepting address 2, error -108
Dec 28 18:45:38 arch kernel: usb 2-3: device not accepting address 2, error -108
Dec 28 18:45:39 arch kernel: usb 2-3: device not accepting address 2, error -108
Dec 28 18:45:39 arch kernel: usb 2-3: USB disconnect, device number 2
…
Dec 28 18:45:39 arch kernel: usb usb2-port3: couldn't allocate usb_device

So this is your usb drive and it wets itself in the context of some ata power juggling

Dec 28 18:44:07 arch kernel: ata1.00: Entering standby power mode
Dec 28 18:44:13 arch kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 28 18:44:13 arch kernel: ata1.00: Entering active power mode
Dec 28 18:44:13 arch kernel: ata1.00: configured for UDMA/133
Dec 28 18:44:13 arch kernel: sd 0:0:0:0: [sda] Starting disk
Dec 28 18:44:33 arch kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
Dec 28 18:44:33 arch kernel: sd 0:0:0:0: [sda] Stopping disk
Dec 28 18:44:33 arch kernel: ata1.00: Entering standby power mode
Dec 28 18:44:40 arch kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 28 18:44:40 arch kernel: ata1.00: Entering active power mode
Dec 28 18:44:40 arch kernel: ata1.00: configured for UDMA/133
Dec 28 18:44:40 arch kernel: sd 0:0:0:0: [sda] Starting disk
…
Dec 28 18:45:32 arch kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
Dec 28 18:45:32 arch kernel: sd 0:0:0:0: [sda] Stopping disk
Dec 28 18:45:32 arch kernel: ata1.00: Entering standby power mode
Dec 28 18:45:36 arch kernel: xhci_hcd 0000:04:00.3: WARNING: Host System Error
Dec 28 18:45:37 arch kernel: usb 2-3: device not accepting address 2, error -108
Dec 28 18:45:37 arch kernel: usb 2-3: device not accepting address 2, error -108
Dec 28 18:45:38 arch kernel: usb 2-3: device not accepting address 2, error -108
Dec 28 18:45:39 arch kernel: usb 2-3: device not accepting address 2, error -108
Dec 28 18:45:39 arch kernel: usb 2-3: USB disconnect, device number 2
Dec 28 18:45:39 arch multipath[23003]: sysfs_is_multipathed: error scanning /sys/block/sdb/holders
Dec 28 18:45:39 arch udisksd[3904]: Couldn't find existing drive object for device /sys/devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb2/2-3/2-3:1.0/host1/target1:0:0/1:0:0:0/block/sdb (uevent action 'change', VPD 'pci-0000:04:00.3-usb-0:3')
Dec 28 18:45:39 arch kernel: usb usb2-port3: couldn't allocate usb_device
Dec 28 18:45:39 arch kernel: r8169 0000:01:00.0 enp1s0: Link is Down
Dec 28 18:45:39 arch virtnodedevd[15736]: Failed to open a VPD file '/sys/bus/pci/devices/0000:01:00.0/vpd': Operation not permitted
Dec 28 18:45:40 arch kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 28 18:45:40 arch kernel: ata1.00: Entering active power mode
Dec 28 18:45:40 arch kernel: ata1.00: configured for UDMA/133
Dec 28 18:45:40 arch kernel: sd 0:0:0:0: [sda] Starting disk

This is btw in line w/ your OP.
See whether you can reproduce this w/o the SanDisk 3.2Gen1 usb key.
Same device recently showed up in https://bbs.archlinux.org/viewtopic.php?id=291219

zoltan · 2023-12-29 20:29:38

It has happened in the past without the SanDisk (or any other USB peripherals or flash media) connected. I don't think I will be able to reliably reproduce this as I've never been able to reproduce it in the past and have no idea what could be triggering it. I'll avoid connecting any USB devices other than my charger and my mouse for the next couple of days. I don't foresee any reason that I'll explicitly need to.

I've also considered grabbing my other mouse and trying to connect it at the same time as the mouse that I'm currently using, the idea being to double the chances (I guess??? lol idk) of this happening.

I'm glad that you pointed out the power juggling. I've noticed that seems to be a common occurrence in all of the logs that I've looked at through the course of this thread. A device will repeatedly power on, then enter standby mode, then power on, then standby, etc., within a very short period of time. Is that normal?

seth · 2023-12-29 22:04:40

Is that normal?

No.
This happens after

Dec 28 18:42:30 arch tlp[22526]: Error: TLP's power saving will not apply on boot because tlp.service is not enabled --> Invoke 'systemctl enable tlp.service' to ensure the full functionality of TLP.
Dec 28 18:42:35 arch tlp[22669]: Error: TLP's power saving will not apply on boot because tlp.service is not enabled --> Invoke 'systemctl enable tlp.service' to ensure the full functionality of TLP.
Dec 28 18:42:35 arch tlp[22807]: Error: TLP's power saving will not apply on boot because tlp.service is not enabled --> Invoke 'systemctl enable tlp.service' to ensure the full functionality of TLP.
Dec 28 18:42:38 arch tlp[22835]: Error: TLP's power saving will not apply on boot because tlp.service is not enabled --> Invoke 'systemctl enable tlp.service' to ensure the full functionality of TLP.

What launches those tlp processes?
What if you completely remove tlp from the system?

zoltan · 2023-12-31 00:43:57

I'm not sure what's launching them. It might be something that I explicitly installed or configured to get power management thresholds working again. I figured after disabling tlp.service, my charging thresholds would no longer work and I would have to go back to manually plugging and unplugging my charger at the desired percentages. However, even after disabling it, my thresholds have continued to work on their own. So there may be something to that.

In any case, I'm going to -Rns tlp. It has two dependencies that are being uninstalled with it: hdparm and iw.

Arch Linux

#1 2023-12-14 20:19:49

[postponed, currently not reproducible]Wireless mouse randomly dis....

Wireless mouse randomly disconnects and won't reconnect until reboot

#2 2023-12-14 22:00:04

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#3 2023-12-14 22:38:30

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#4 2023-12-15 08:51:16

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#5 2023-12-15 09:23:07

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#6 2023-12-17 20:48:20

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#7 2023-12-17 21:10:57

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#8 2023-12-19 21:20:41

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#9 2023-12-19 21:23:22

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#10 2023-12-19 21:35:55

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#11 2023-12-19 21:51:33

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#12 2023-12-20 02:13:47

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#13 2023-12-22 21:39:54

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#14 2023-12-22 21:46:50

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#15 2023-12-22 22:13:43

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#16 2023-12-22 22:18:03

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#17 2023-12-22 23:12:04

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#18 2023-12-23 08:09:55

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#19 2023-12-25 16:36:57

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#20 2023-12-25 20:57:07

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#21 2023-12-29 02:40:10

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#22 2023-12-29 13:49:05

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#23 2023-12-29 20:29:38

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#24 2023-12-29 22:04:40

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

#25 2023-12-31 00:43:57

Re: [postponed, currently not reproducible]Wireless mouse randomly dis....

Board footer