The Problem
Hi. I am using an MSI B450 Tomahawk MAX with a Ryzen 5 3600 CPU and in the past few weeks a serious issue has cropped up where while just using Linux normally suddenly my mouse stops working (lights stay on but cursor is unresponsive) but my keyboard carries on working. From further testing I’ve identified that this also affects the 2 USB 2.0 ports on my motherboard and the 2 USB 3.0 ports on my case. After this issue occurs if I unplug my mouse and plug it back into one of the affected ports the lights don’t even turn on (same goes for keyboard).
It is worth noting that I have a high end gaming mouse (Razer Naga Trinity) and I know that there is a history of such mice causing problems in Linux but I think this is more related to a driver as somehow I doubt that one mouse could take down 4 different USB ports. I’ve also had this mouse for a long time and the issue never occurred before a few weeks ago.
If I plug any USB device e.g. USB sticks or wireless adapters into the affected ports the fail to get initialised at all (no lights and no data transmission). Sometimes when the problem occurs looking at the output of dmesg revivals lines such as:
usb 2-3: device descriptor read/8, error -110usb 2-3: new SuperSpeed Gen 1 USB device number 7 using xhci_hcdusb usb2-port3: attempt power cycleusb 1-2.1: Failed to suspend device, error -110usb usb2-port3: unable to enumerate USB device
usb 2-3 and USB device number 7 get swapped out for different numbers throughout the log. These messages do not always occur when the issue happens though.
What I’ve tried to fix it
I already posted about the issue briefly on this unrelated thread because I originally thought it was a problem with Wayland, I quickly realised this wasn’t the case. Anyway somebody replied that it might be related to USB legacy mode being enabled in the BIOS
I tried disabling that and XHCI hand off in the same vain since they are both only useful for legacy OSes. Since this was a new issue I also tried downgrading my BIOS to an older version (might try going even older later)
Other than that the only thing I could think of was to switch from Arch Linux to Pop_OS! 20.10 in the hopes it was something exclusive to Arch. I couldn’t find much other info on the topic sadly.
Conclusion
If there is any more info I can post to help (logs, details etc) I would be happy to do so and hopefully I can get this problem sorted soon. I’m grateful in advance for replies 
Specs
- CPU: Ryzen 5 3600
- GPU: AMD RX 5700
- Mobo: MSI B450 Tomahawk MAX
- RAM: 8 GB (2 * 4 GB) DDR4 @ 2400Mhz
- SSD: 256 GB Crucial MX500 SATA
Before going mad lad on this issue, have you tried just using a different mouse for a little while?
I’d do that first just to take the mouse out of the equation. If it works fine with a different mouse you have your answer, if not, you’ve got something odd going on with your USB ports. I’ve seen behavior like this with a shorted cable in a hub before so other devices could be the culprit as well.
Yes I will try that. The only other mouse I have is also a gaming mouse but its a less exotic one than what I’ve got plugged in now so still worth trying. I don’t have any USB hubs plugged in and I also have a Windows 10 install where the problem never occurs which is why I thought It would be a Linux driver problem and not a hardware issue.
1 Like
I once had a PC with a shorted USB plug that never showed any errors in windows, but when I used linux I got a bunch of system errors. Not sure why windows didn’t show the problem, but when I looked at the port it was physically broken (smashed) on the board.
Huh I guess maybe Windows has some kind of system to correct for issues like that and carry on as normal. After I’ve finished testing this mouse I’ll check my USB ports for physical damage.
EDIT: My other mouse just had the issue so I can safely rule out the mouse as the culprit. I’m gonna try disconnecting all of my oculus rift devices as a friend of mine speculated they might be sending too much data for the USB driver in Linux to handle.
Tanks for including the dmesg output. You might be suffering from a USB low power mode that was turned on in I think Kernel 5.4.
If you are on arch, you may need to make sure that you are running the latest board firmware and CPU microcode.
https://wiki.archlinux.org/index.php/Ryzen#Enable_microcode_support
I remember hearing about the USB freezing issues but since i am not on Ryzen, I did not pay much attention because I was waiting for Zen 3 anyway.
I always recommend trying to fix the issue before distro hopping. Unless the issue is related to kernel version, if it is a driver issue, more than likely hopping distros will not fix the issue.
That would defiantly make sense but on arch I did have microcode installed and I believe it is pre baked on Ubuntu and by extension Pop_OS!. Do you know of any other way to disable low power mode/suspend because I really have no need for it.
I’m also quite hopeful about my idea of unplugging my Oculus Rift hardware because it may be sending too much data for the USB driver to handle: 3 different sensors (essentially infrared cameras) constantly sending wide angle images to the computer.
Or they might be causing some other incompatibility since that hardware was only meant to be used on Windows with the Oculus driver installed to regulate it.
Thanks. My rules file that looks like this now:
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1532", ATTR{idProduct}="0067"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="04d9", ATTR{idProduct}="0356", GOTO="power_usb_rules_end"
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"
LABEL="power_usb_rules_end"
I wasn’t quite sure how to do this for multiple devices (My keyboard and my mouse), does this look right to you?
Looks good to me. That vendor and product IDs matches for both devices (should not), then you should be good. Otherwise, you will need to do it per device ID.
They don’t match. The first one is 1532:0067 and the second one is 04d9:0356
Bus 001 Device 003: ID 1532:0067 Razer USA, Ltd Naga Trinity
Bus 001 Device 004: ID 04d9:0356 Holtek Semiconductor, Inc. Ducky Keyboard
? Sorry if I’m missing something obvious
So do
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1532", ATTR{idProduct}="0067", GOTO="power_usb_rules_end"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="04d9", ATTR{idProduct}="0356", GOTO="power_usb_rules_end"
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"
LABEL="power_usb_rules_end"
**Edit
The first two rules essentially tell udev to do nothing when it sees those specific devices.
The third item says, enable auto suspend for all USB devices as they register (accept for what is explicitly specified before this)
The fourth line is just a label. It does nothing. The first to go to the label and there is no follow up action, so it does nothing with them so it should carry on with system defaults, unless your system defaults to auto power management. You can also just turn it off explicitly for those devices with
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1532", ATTR{idProduct}="0067", ATTR{power/control}="off"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="04d9", ATTR{idProduct}="0356", ATTR{power/control}="off"
1 Like
Ah okay thanks. I thought I should leave out the goto on the first line in case it skipped to the end of the file and didn’t process the second line.
No, udev is event based. Anytime some hardware change happens, it looks to see if there is an override to how it should handle the action.
The order of the items in the file determines precedence of how the rule is applied per item. That is why you put the most explicit stuff up top and least at the bottom. the first example exploits this fact and says, hey, if you see this specific device, go to the label and do what it says. In this case, the label does nothing. Eventually an device that fits the USB sub system but does not match one of the explicit vendor and device mentioned will hit the catch all rule.
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"
Does that make sense? Think of like order of operations in mathematics.
1 Like
Ah gotcha thanks. So basically every time a USB device matching those ids is detected it goes to the end of the file and does nothing (doesn’t enable auto suspend) and whenever another device is detected not matching those ids it skips the first 2 lines because they don’t apply and only processes the line where auto suspend is enabled.
Yep. Like i mentioned, The first holds true only if your system does not default to auto power management or power management on. But you understand or of precedence now.
I did understand the concept of order of precedence already because I have done some minor coding projects but I though that this file would only be read once which is what confused me. Probably should of looked into udev before commenting xD.
It’s all good. I hope that it makes a difference for you.
Thanks. in the past few hours after unplugging my rift the issue hasn’t happened so I’m very hopeful that has fixed it . If it does turn out that was the solution I’m going that have to find some way of keeping the rift plugged in but disabled in Linux because it would be a real pain if I had to connect all the different cables when I want to play VR in Windows. Perhaps disabling auto suspend on the rift hardware will fix the issue. 
That may do it.
You can also just turn off certain ports too. Turning off power save for the Rift may be the easier answer short of just unplugging the USB devices.
https://bbs.archlinux.org/viewtopic.php?id=233948