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.

-- 

*C J Evans *