You are not logged in.
Pages: 1
I've just bought a new whizz-bang computer, Intel 8700K, Nvidia GPU, etc., but I'm having trouble with my keyboard. I've previously used the same peripherals on my laptop perfectly fine. However, now the keyboard regularly freezes up. Keys don't register, then get "stuck" down. journalctl shows the following errors.
Jan 12 21:05:11 hostname kernel: usb 1-3.3: reset full-speed USB device number 5 using xhci_hcd
Jan 12 21:05:45 hostname kernel: usb 1-3.3: reset full-speed USB device number 5 using xhci_hcd
Jan 12 21:05:52 hostname kernel: usb 1-3.3: reset full-speed USB device number 5 using xhci_hcd
Jan 12 21:06:16 hostname kernel: usb 1-3.3: reset full-speed USB device number 5 using xhci_hcd
Jan 12 21:06:57 hostname kernel: usb 1-3.3: reset full-speed USB device number 5 using xhci_hcd
It happens intermittently, up to five times in a minute for several minutes, then not at all for half an hour. Perhaps it tends to occur more after a suspend/resume cycle, but that's just a small hunch.
I'm using the nvidia drivers, but I've also tried booting with linux-lts/nvidia-lts, although that doesn't solve the problem.
I'm wondering if it might be a dodgy motherboard, but I'm not sure how to check. I was considering installing Ubuntu, but if I don't see the problem, I still wouldn't rule out hardware, because it's so intermittent anyway. Any suggestions?
Last edited by Salkay (2018-01-18 09:08:02)
Offline
Try some live distro (ubuntu, grml, knoppix, ...) to rule out HW issues.
Offline
Check (and double check) that your keyboard is plugged in a USB2 port and not a USB3 port. That was causing me issues with my new computer...
Offline
Thank you both for the replies.
Try some live distro (ubuntu, grml, knoppix, ...) to rule out HW issues.
Good idea, but potentially I'd run into the same problems with intermittency. If I see nothing for half an hour, it doesn't mean there is no issue. Still, might be worth a try.
Check (and double check) that your keyboard is plugged in a USB2 port and not a USB3 port. That was causing me issues with my new computer...
Hmm, it was plugged into a USB3 port. I've moved it to a USB2 port. However, why might that cause a problem? Shouldn't USB2 hubs/devices work in either type of port?
Offline
Shouldn't USB2 hubs/devices work in either type of port?
Yes, but we don't live in a shouldland ;-)
https://marc.info/?l=linux-usb&m=137714769606183&w=2
You could also try to inject the device into a USB3 slot but blacklist xhci_hcd and see what happens.
Offline
Good point, I stand corrected!
I didn't understand all of that, but there are clearly issues with the xHCI drivers. However, do you know if the implication is that all USB devices (including USB3 hard drives, for example) are affected, or is this just talking about USB2 things (e.g. keyboards).
Offline
Hmmm… I'm still getting resets even after connecting the hub to the USB2 port. There's nothing connected to the USB3 port.
Jan 13 19:40:30 hostname kernel: usb 1-12.3: reset full-speed USB device number 5 using xhci_hcd
Jan 13 19:40:32 hostname kernel: usb 1-12.3: reset full-speed USB device number 5 using xhci_hcd
Jan 13 19:40:33 hostname kernel: usb 1-12.3: reset full-speed USB device number 5 using xhci_hcd
Jan 13 19:40:35 hostname kernel: usb 1-12.3: reset full-speed USB device number 5 using xhci_hcd
Jan 13 19:40:39 hostname kernel: usb 1-12.3: reset full-speed USB device number 5 using xhci_hcd
The keyboard is still skipping keys too. Here is confirmation of the connected port.
$ lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
|__ Port 12: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 2: Dev 4, If 0, Class=Vendor Specific Class, Driver=xpad, 12M
|__ Port 2: Dev 4, If 1, Class=Vendor Specific Class, Driver=, 12M
|__ Port 2: Dev 4, If 2, Class=Vendor Specific Class, Driver=, 12M
|__ Port 2: Dev 4, If 3, Class=Vendor Specific Class, Driver=, 12M
|__ Port 3: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 3: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 12M
Actually, I thought that xhci_hcd meant it was USB3? But here it says 480M?
Last edited by Salkay (2018-01-13 09:16:22)
Offline
Still
using xhci_hcd
https://wiki.archlinux.org/index.php/Ke … acklisting
Use the "/bin/false" method. USB should then be covered by ehci, your USB3 external drive will be slow - but we should be able to figure whether this still happens even with ehci.
If not, we might face an issue with power saving or the HW.
Offline
To update, before trying seth's suggestion, I tried removing an old xbox 360 controller that was attached to the USB hub. Since then, I don't see the chronic problems that I had before. To clarify, I still do see the reset, but extremely infrequently. I suspect it's only when resuming from suspend.
It's a bit odd, because this controller was connected to the hub when it was connected to my old laptop, and never caused issues then. I'll try attaching it to another usb port, and see if it has any effect.
Offline
And… plugging the controller into its own port seems to have fixed it. I wonder if it were an issue of drawing too much power from a single USB port? Thanks seth and drcouzelis for your help!
Offline
Pages: 1