Every now and then during use, the USB will just completely die and will not come back up until a reboot comes along.
A potentially similar issue I’ve got is during boot up, my mouse does not initialise and requires replugging in.
I’m happy to provide more information. I just have no idea if this a hardware issue or software.
I have a small gut feeling that it is the Unmatched trying to sleep, and subsequently has disconnected the keyboard and mouse. I’ve disabled the anything I could find regarding sleep timeouts in the Gnome control centre, but alas to no avail.
This is also mentioned in the HiFive Unleashed Software Reference Manual which can be found on the HiFive Unmatched board page. https://www.sifive.com/boards/hifive-unmatched
This suggests another workaround. This is section 8.11.
This problem primarily affects HID I think, e.g. keyboard and mouse.
I noticed that as well. Close to unusable with a HUB (to which I had mouse + KB attached) but it works ‘better’ when attaching both individually. For me a simple unplug/replug solves the issue every time. It remains annoying though. Using freedrom-u-sdk 2021.06.
It happened a lot back when I used a wireless keyboard/mouse combo. It would just stop responding until reconnect.
Now with a separately, directly connected (and wired) keyboard and mouse, it almost never happens. I only remember having to replug after reboot. Ok, it keeps happening. When it happens:
The device still shows up in lsusb
The device stlll shows up in evtest. However, no events appear when keys are pressed.
It’s still powered (leds are on)
I checked raw bus traffic using cat /sys/kernel/debug/usb/usbmon/1u (where the device is connected to bus 1). Nothing at all.
Replugging always solved the issue (for at least a few minutes, usually longer) for me, I’ve never had USB crash completely until a reboot.
I’ve only ever noticed it with HID devices (mouse, keyboard, but also with a Wacom drawing tablet), not with other USB-connected devices such as UARTs, even on the same bus as the hanging device!
Edit: I’ve connected a PCI-e USB controller, let’s see if it happens with that too or not.
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
|__ Port 1: Dev 15, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 1: Dev 15, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
Plugging the keyboard into port marked “1”
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
|__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 14, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 3: Dev 14, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
Plugging the keyboard into port marked “2”
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
|__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 2: Dev 16, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 2: Dev 16, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
Plugging the keyboard into port marked “3”
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
|__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 17, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 1: Dev 17, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
There’s a clear difference between the first port (I assume you mean port 0), which is connected directly to the root hub and the rest, which is nested behind a hub. I wonder if this explains the difference in behavior.
Yes, first port meaning port 0. I think you’re right about the reason for the difference.
If there is a hardware issue with the onboard hub for ports 1,2, and 3 maybe this can be bypassed by hooking up a known working external hub on port 0 and plugging both mouse and keyboard into that?
I would really appreciate any solutions in that area. I use the unmatched as desktop. Sharing screen with the laptop and the disconnects really limit the fun (that original fan sure also did but it’s okay with a 40mm one now)…
So whoever finds something has my eternal gratitude.
The ‘nuclear option’ would be to connect a different USB controller through PCI-e (like i did in M-2 E key to PCI-e + USB2 adapter - #8 by vmedea), or running USB via an external host through usbip.
Something I haven’t been able to try yet is whether the /sys/devices unbind-bind sequence described here works: keyboard - USB slots stop working suddenly from time to time - Ask Ubuntu If it would at least be possible to unstuck the USB without having to physically replug it’d save some frustration, and could ostensibly even be done automatically, if the situation can be detected.
