lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bf0fda83-d97d-4a50-94d6-a2d70607a917@gmail.com>
Date: Sat, 8 Mar 2025 23:19:22 +0000
From: Colin Evans <colin.evans.parkstone@...il.com>
To: Alan Stern <stern@...land.harvard.edu>
Cc: eichest@...il.com, francesco.dolcini@...adex.com,
 gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
 linux-usb@...r.kernel.org, stable@...r.kernel.org,
 stefan.eichenberger@...adex.com
Subject: Re: [PATCH v1] usb: core: fix pipe creation for get_bMaxPacketSize0

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 *

View attachment "lsusb_t_problem.txt" of type "text/plain" (2665 bytes)

View attachment "lsusb_t_working,txt" of type "text/plain" (2950 bytes)

View attachment "usbmon_problem.txt" of type "text/plain" (4974290 bytes)

View attachment "usbmon_working.txt" of type "text/plain" (73724 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ