On 06/03/2025 21:43, Alan Stern wrote:
On Thu, Mar 06, 2025 at 09:06:23PM +0000, Colin Evans wrote:
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
Happy to try this, but as it stands there is no such file, or file-like thing, on my machine-
# ls /sys/kernel/debug/usb/usbmon/2u ls: cannot access '/sys/kernel/debug/usb/usbmon/2u': No such file or directory
# find /sys/kernel/debug/usb -name "2u" #
# ls /sys/kernel/debug/usb devices ehci ohci uhci uvcvideo xhci
It seems something is missing?
Ah -- you have to load the usbmon module first:
modprobe usbmon
Some distributions do this for you automatically.
Alan Stern
------------------------------------------------------
I believe I have the information requested. The output of usbmon for the "problem" scenario is large, I hope it doesn't exceed any email attachment limits, but if it does I will have to work out another way to share it.
It may be that 30s of data is more than is needed. If that's the case I can easily run a shorter usbmon cycle.
Additional Observations ----------------------- It appears that having pretty much any external device plugged into a motherboard port connected to the _problem_ controller is enough to suppress the stream of "usb usb2-port4: Cannot enable. Maybe the USB cable is bad?" dmesg errors.
For these tests the results named "working" had a USB2.0 memory stick plugged into one of the top 4 USB ports on the motherboard, while the "problem" results didn't.
For info- the older machine that exhibits this problem ("machine 1") also shows device manager errors if booted into Windows 10, suggesting that machine may in fact have a motherboard hardware fault.
However "machine 2" (which is less than 2 weeks old), shows no errors when booted into Windows.
How the Results Were Generated ------------------------------
"working" results ----------------- The command string used (after "modprobe usbmon") was-
timeout -k 30 30 echo 0 >/sys/bus/usb/devices/usb2/bConfigurationValue ; \ cat /sys/kernel/debug/usb/usbmon/2u >usbmon_filename.txt & \ echo 1 >/sys/bus/usb/devices/usb2/bConfigurationValue
I booted the machine with the USB stick connected, checked that there were no dmesg error and the performance of 'lsusb' was sane, then ran the command above. I also ran-
lsusb -t > lsusb_t_filename.txt To document the USB device structure. "problem" results ----------------- Rebooted the machine with nothing connected to the problem USB ports. Confirmed the issue was present (slow boot, dmesg errors etc.) Re-ran the same commands. I hope this gives the information required.