On Wed, Mar 05, 2025 at 10:02:15PM +0000, incansvl wrote:
Team,
I am experiencing a problem on multiple versions of the 6.x kernel, where initialisation of a motherboard usb hub device fails and causes a stream of errors. The performance of the machine is badly affected.
I would have considered this most likely a hardware fault except-
- I am seeing the same issue on 2 machines of very different age and spec.
The differences may not matter if they use similar hardware components.
- In each case the hub generating errors has no external devices connected to it, so the error can't be caused by an external device that has failed. In fact on "machine 2", having no devices plugged in seems to be a necessary condition for the error to occur (see details below).
I found the discussion of this patch, but I am not clear about this description-
I suspect that patch has nothing to do with your problem. Have you tried applying (or reverting) it to see if that causes the problem to go away?
- On both machines the errors relate to a USB root hub that has NO DEVICES connected to it. On "machine 2", having a powered USB3.0 hub (which has a number of downstream devices connected) plugged in to one port on the hub is enough to suppress the errors, although I note the that "bad" port number (hub 2 : port 3) is not enumerated (skipped?).
(tail of "dmesg -w") [ 781.020436] usb usb2-port3: Cannot enable. Maybe the USB cable is bad? [ 784.990637] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
...
Please try collecting a usbmon trace for bus 2 showing the problem. Ideally the trace should show what happens from system boot-up, but there's no way to do that. Instead, you can do this (the first command below disables the bus, the second starts the usbmon trace, and the third re-enables the bus):
echo 0 >/sys/bus/usb/devices/usb2/bConfigurationValue cat /sys/kernel/debug/usb/usbmon/2u >usbmon.txt & echo 1 >/sys/bus/usb/devices/usb2/bConfigurationValue
Then after enough time has passed for the errors to show up, kill the "cat" process and post the resulting trace file. (Note: If your keyboard is attached to bus 2, you won't be able to use it to issue the second and third commands. You could use a network login, or put the commands into a shell file and run them that way.)
In fact, you should do this twice: The second time, run it on machine 2 with the powered hub plugged in to suppress the errors.
Alan Stern