[PATCH v1] usb: core: fix pipe creation for get_bMaxPacketSize0

[PATCH v1] usb: core: fix pipe creation for get_bMaxPacketSize0

[Stefan Eichenberger]

From: Stefan Eichenberger <stefan.eichenberger@toradex.com>

When usb_control_msg is used in the get_bMaxPacketSize0 function, the
USB pipe does not include the endpoint device number. This can cause
failures when a usb hub port is reinitialized after encountering a bad
cable connection. As a result, the system logs the following error
messages:
usb usb2-port1: cannot reset (err = -32)
usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
usb usb2-port1: attempt power cycle
usb 2-1: new high-speed USB device number 5 using ci_hdrc
usb 2-1: device descriptor read/8, error -71

The problem began after commit 85d07c556216 ("USB: core: Unite old
scheme and new scheme descriptor reads"). There
usb_get_device_descriptor was replaced with get_bMaxPacketSize0. Unlike
usb_get_device_descriptor, the get_bMaxPacketSize0 function uses the
macro usb_rcvaddr0pipe, which does not include the endpoint device
number. usb_get_device_descriptor, on the other hand, used the macro
usb_rcvctrlpipe, which includes the endpoint device number.

By modifying the get_bMaxPacketSize0 function to use usb_rcvctrlpipe
instead of usb_rcvaddr0pipe, the issue can be resolved. This change will
ensure that the endpoint device number is included in the USB pipe,
preventing reinitialization failures. If the endpoint has not set the
device number yet, it will still work because the device number is 0 in
udev.

Cc: stable@vger.kernel.org
Fixes: 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads")
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
---
Before commit  85d07c556216 ("USB: core: Unite old scheme and new scheme
descriptor reads") usb_rcvaddr0pipe was used in hub_port_init. With this
proposed change, usb_rcvctrlpipe will be used which includes devnum for
the pipe. I'm not sure if this might have some side effects. However, my
understanding is that devnum is set to the right value (might also be 0
if not initialised) before get_bMaxPacketSize0 is called. Therefore,
this should work but please let me know if I'm wrong on this.
---
 drivers/usb/core/hub.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index c3f839637cb5..59e38780f76d 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4698,7 +4698,6 @@ void usb_ep0_reinit(struct usb_device *udev)
 EXPORT_SYMBOL_GPL(usb_ep0_reinit);
 
 #define usb_sndaddr0pipe()	(PIPE_CONTROL << 30)
-#define usb_rcvaddr0pipe()	((PIPE_CONTROL << 30) | USB_DIR_IN)
 
 static int hub_set_address(struct usb_device *udev, int devnum)
 {
@@ -4804,7 +4803,7 @@ static int get_bMaxPacketSize0(struct usb_device *udev,
 	for (i = 0; i < GET_MAXPACKET0_TRIES; ++i) {
 		/* Start with invalid values in case the transfer fails */
 		buf->bDescriptorType = buf->bMaxPacketSize0 = 0;
-		rc = usb_control_msg(udev, usb_rcvaddr0pipe(),
+		rc = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
 				USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
 				USB_DT_DEVICE << 8, 0,
 				buf, size,
-- 
2.45.2

Re: [PATCH v1] usb: core: fix pipe creation for get_bMaxPacketSize0

[Alan Stern]

On Mon, Feb 03, 2025 at 11:58:24AM +0100, Stefan Eichenberger wrote:
> From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> 
> When usb_control_msg is used in the get_bMaxPacketSize0 function, the
> USB pipe does not include the endpoint device number. This can cause
> failures when a usb hub port is reinitialized after encountering a bad
> cable connection. As a result, the system logs the following error
> messages:
> usb usb2-port1: cannot reset (err = -32)
> usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
> usb usb2-port1: attempt power cycle
> usb 2-1: new high-speed USB device number 5 using ci_hdrc
> usb 2-1: device descriptor read/8, error -71
> 
> The problem began after commit 85d07c556216 ("USB: core: Unite old
> scheme and new scheme descriptor reads"). There
> usb_get_device_descriptor was replaced with get_bMaxPacketSize0. Unlike
> usb_get_device_descriptor, the get_bMaxPacketSize0 function uses the
> macro usb_rcvaddr0pipe, which does not include the endpoint device
> number. usb_get_device_descriptor, on the other hand, used the macro
> usb_rcvctrlpipe, which includes the endpoint device number.
> 
> By modifying the get_bMaxPacketSize0 function to use usb_rcvctrlpipe
> instead of usb_rcvaddr0pipe, the issue can be resolved. This change will
> ensure that the endpoint device number is included in the USB pipe,
> preventing reinitialization failures. If the endpoint has not set the
> device number yet, it will still work because the device number is 0 in
> udev.
> 
> Cc: stable@vger.kernel.org
> Fixes: 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads")
> Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> ---
> Before commit  85d07c556216 ("USB: core: Unite old scheme and new scheme
> descriptor reads") usb_rcvaddr0pipe was used in hub_port_init. With this
> proposed change, usb_rcvctrlpipe will be used which includes devnum for
> the pipe. I'm not sure if this might have some side effects. However, my
> understanding is that devnum is set to the right value (might also be 0
> if not initialised) before get_bMaxPacketSize0 is called. Therefore,
> this should work but please let me know if I'm wrong on this.

I believe you are correct.  This is a pretty glaring mistake; I'm 
surprised that it hasn't show up before now.  Thanks for fixing it.

Reviewed-by: Alan Stern <stern@rowland.harvard.edu>

In fact, it looks like usb_sndaddr0pipe is used in only one place and it 
can similarly be replaced by usb_sndctrlpipe, if you want to make that 
change as well (although this usage is not actually a mistake).

Alan Stern

> ---
>  drivers/usb/core/hub.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index c3f839637cb5..59e38780f76d 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -4698,7 +4698,6 @@ void usb_ep0_reinit(struct usb_device *udev)
>  EXPORT_SYMBOL_GPL(usb_ep0_reinit);
>  
>  #define usb_sndaddr0pipe()	(PIPE_CONTROL << 30)
> -#define usb_rcvaddr0pipe()	((PIPE_CONTROL << 30) | USB_DIR_IN)
>  
>  static int hub_set_address(struct usb_device *udev, int devnum)
>  {
> @@ -4804,7 +4803,7 @@ static int get_bMaxPacketSize0(struct usb_device *udev,
>  	for (i = 0; i < GET_MAXPACKET0_TRIES; ++i) {
>  		/* Start with invalid values in case the transfer fails */
>  		buf->bDescriptorType = buf->bMaxPacketSize0 = 0;
> -		rc = usb_control_msg(udev, usb_rcvaddr0pipe(),
> +		rc = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
>  				USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
>  				USB_DT_DEVICE << 8, 0,
>  				buf, size,
> -- 
> 2.45.2
> 

Re: [PATCH v1] usb: core: fix pipe creation for get_bMaxPacketSize0

[Stefan Eichenberger]

On Mon, Feb 03, 2025 at 11:02:37AM -0500, Alan Stern wrote:
> On Mon, Feb 03, 2025 at 11:58:24AM +0100, Stefan Eichenberger wrote:
> > From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> > 
> > When usb_control_msg is used in the get_bMaxPacketSize0 function, the
> > USB pipe does not include the endpoint device number. This can cause
> > failures when a usb hub port is reinitialized after encountering a bad
> > cable connection. As a result, the system logs the following error
> > messages:
> > usb usb2-port1: cannot reset (err = -32)
> > usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
> > usb usb2-port1: attempt power cycle
> > usb 2-1: new high-speed USB device number 5 using ci_hdrc
> > usb 2-1: device descriptor read/8, error -71
> > 
> > The problem began after commit 85d07c556216 ("USB: core: Unite old
> > scheme and new scheme descriptor reads"). There
> > usb_get_device_descriptor was replaced with get_bMaxPacketSize0. Unlike
> > usb_get_device_descriptor, the get_bMaxPacketSize0 function uses the
> > macro usb_rcvaddr0pipe, which does not include the endpoint device
> > number. usb_get_device_descriptor, on the other hand, used the macro
> > usb_rcvctrlpipe, which includes the endpoint device number.
> > 
> > By modifying the get_bMaxPacketSize0 function to use usb_rcvctrlpipe
> > instead of usb_rcvaddr0pipe, the issue can be resolved. This change will
> > ensure that the endpoint device number is included in the USB pipe,
> > preventing reinitialization failures. If the endpoint has not set the
> > device number yet, it will still work because the device number is 0 in
> > udev.
> > 
> > Cc: stable@vger.kernel.org
> > Fixes: 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads")
> > Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> > ---
> > Before commit  85d07c556216 ("USB: core: Unite old scheme and new scheme
> > descriptor reads") usb_rcvaddr0pipe was used in hub_port_init. With this
> > proposed change, usb_rcvctrlpipe will be used which includes devnum for
> > the pipe. I'm not sure if this might have some side effects. However, my
> > understanding is that devnum is set to the right value (might also be 0
> > if not initialised) before get_bMaxPacketSize0 is called. Therefore,
> > this should work but please let me know if I'm wrong on this.
> 
> I believe you are correct.  This is a pretty glaring mistake; I'm 
> surprised that it hasn't show up before now.  Thanks for fixing it.
> 
> Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
> 
> In fact, it looks like usb_sndaddr0pipe is used in only one place and it 
> can similarly be replaced by usb_sndctrlpipe, if you want to make that 
> change as well (although this usage is not actually a mistake).

Thanks a lot for the feedback. I was also thinking, if this macro is
required. I will wait a few more days to see if no one else has any
objection and if not I will send an additional patch to also replace
usb_sndaddr0pipe with usb_sndctrlpipe.

Regards,
Stefan

Re: [PATCH v1] usb: core: fix pipe creation for get_bMaxPacketSize0

[incansvl]

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-

1) I am seeing the same issue on 2 machines of very different age and spec.
2) 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-

> > When usb_control_msg is used in the get_bMaxPacketSize0 function, the > > USB pipe does not include the endpoint device number. This can 
cause > > failures when a usb hub port is reinitialized after 
encountering a bad > > cable connection. As a result, the system logs 
the following error > > messages: > > usb usb2-port1: cannot reset (err 
= -32) > > usb usb2-port1: Cannot enable. Maybe the USB cable is bad? > 
 > usb usb2-port1: attempt power cycle > > usb 2-1: new high-speed USB 
device number 5 using ci_hdrc > > usb 2-1: device descriptor read/8, 
error -71 If this is saying that ALL of these error messages will be issued for each "bad" port,
that is not what i'm seeing, and I might have a new issue to report.

However if the description above means that ANY ONE OF these errors might be issued, and
that single error will be consistent and repeatable for a specific kernel+hardware combo,
then that is consistent with the problem I am seeing.

I have included more information below to help determine if this IS the same issue or not.
If it is not the same issue, and not yours to look into, I would appreciate your steer on
which maintainer + mailing list to forward it to.

Regards: Incans


------------------------ Additional Info ------------------------

Symptoms
--------

1) From boot, the console then dmesg show repeated messages of the form:

        |usb usb2-port3: Cannot enable. Maybe the USB cable is bad?|

|2) Performance is badly affected. Boot and login times can be 10x or 
more slower than a comparable (in fact slower) machine running a 5.x 
kernel. Desktop Environment (KDE Plasma) performance and stability are 
both impacted. E.g. in KDE panel widgets can stop updating requiring a 
plasmashell (Wayland) restart 3) A "canary" command to show the error is 
lsusb. This will show symptoms like- * lsusb run as root (sudo) can be 
30-100x slower than when run as normal user * A variant such as "lsusb 
-t" might sidestep the performance problem and run in a 'sane' amount of 
time |

4) 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?).


Software Versions
-----------------
I have seen the same errors in:

OS: KDE neon 6.3 (Wayland)                       Kernel: 6.11.0-17-generic (64-bit)
OS: EndeavourOS (2025-03-05)(KDE 6.3.2 Wayland)  Kernel: 6.13.5-arch1-1 (64-bit)
OS: EndeavourOS (2025-03-05)(KDE 6.3.2 Wayland)  Kernel: linux-lts 6.12.17-1


Hardware
--------

*Machine 1*
Processors: Intel® i7-6700K 4 Core 8 Thread @ 4.60GHz
Memory: 32 GiB RAM
GPU: AMD Radeon RX 6700 XT
Motherboard: Gigabyte Z170X-GamingG1
Primary Disk: Orico 4TB NVME (Gen4 but limited to Gen 2 by motherboard)

*Machine 2*
Processors: AMD Ryzen 7 7700 8 Core 16 Thread @ 5.3GHz
Memory: 32 GiB RAM
GPU: AMD Radeon RX 6700 XT
Motherboard: ASRock B650 LiveMixer
Primary Disk: Orico 4TB NVME (Gen4, motherboard supports up to Gen 5)


Example (Taken from Machine 1 while the problem is active)
----------------------------------------------------------

$ sudo -s
[root@EdeavourOS admin]# time lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 045b:0209 Hitachi, Ltd
Bus 001 Device 003: ID 045b:0209 Hitachi, Ltd
Bus 001 Device 004: ID 045e:07f8 Microsoft Corp. Wired Keyboard 600
(model 1576)
Bus 001 Device 005: ID 0cf3:e300 Qualcomm Atheros Communications QCA61x4
Bluetooth 4.0
Bus 001 Device 006: ID 045e:00cb Microsoft Corp. Basic Optical Mouse v2.0
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 045b:0210 Hitachi, Ltd
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

real    0m22.861s
user    0m0.031s
sys     0m0.013s


[root@EdeavourOS admin]# time lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/16p, 480M
     |__ Port 003: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M
         |__ Port 001: Dev 004, If 0, Class=Human Interface Device,
Driver=usbhid, 1.5M
         |__ Port 001: Dev 004, If 1, Class=Human Interface Device,
Driver=usbhid, 1.5M
         |__ Port 002: Dev 006, If 0, Class=Human Interface Device,
Driver=usbhid, 1.5M
     |__ Port 004: Dev 003, If 0, Class=Hub, Driver=hub/4p, 480M
     |__ Port 013: Dev 005, If 0, Class=Wireless, Driver=btusb, 12M
     |__ Port 013: Dev 005, If 1, Class=Wireless, Driver=btusb, 12M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/10p, 5000M
     |__ Port 004: Dev 002, If 0, Class=Hub, Driver=hub/4p, 5000M
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M

real    0m0.024s
user    0m0.013s
sys     0m0.011s


(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?
[  788.960543] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[  792.933684] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[  796.906907] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[  800.883545] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[  804.863692] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[  808.840075] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[  812.810130] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[  816.790281] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[  820.783424] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[  824.760157] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?
[  828.730143] usb usb2-port3: Cannot enable. Maybe the USB cable is bad?

Re: [PATCH v1] usb: core: fix pipe creation for get_bMaxPacketSize0

[Alan Stern]

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-
> 
> 1) 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.

> 2) 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?

> 4) 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

Re: [PATCH v1] usb: core: fix pipe creation for get_bMaxPacketSize0

[Alan Stern]

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

Re: [PATCH v1] usb: core: fix pipe creation for get_bMaxPacketSize0

[Alan Stern]

On Sat, Mar 08, 2025 at 11:19:22PM +0000, Colin Evans wrote:
> 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.

It is a lot more than needed, but that's okay.

> 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.

Well, I have no idea what Windows is doing on that machine.

The usbmon trace shows that port 4 on bus 2 generates a continual
stream of link-state-change events, constantly interrupting the system
and consuming computational resources.  That's why the performance
goes way down.

I can't tell what's causing those link-state changes.  It _looks_ like
what you would get if there was an intermittent electrical connection
causing random voltage fluctuations.  Whatever the cause is, plugging
in the memory stick does seem to suppress those changes; they don't
show up at all in the "working" trace.

In theory, turning off power to port 4 might stop all the events from
being reported.  You can try this to see if it works:

	echo 1 >/sys/bus/usb/devices/2-0:1.0/usb2-port4/disable

Alan Stern

Re: [PATCH v1] usb: core: fix pipe creation for get_bMaxPacketSize0

[Colin Evans]

On 09/03/2025 21:01, Alan Stern wrote:
> On Sat, Mar 08, 2025 at 11:19:22PM +0000, Colin Evans wrote:
>> 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.
> It is a lot more than needed, but that's okay.
>
>> 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.
> Well, I have no idea what Windows is doing on that machine.
>
> The usbmon trace shows that port 4 on bus 2 generates a continual
> stream of link-state-change events, constantly interrupting the system
> and consuming computational resources.  That's why the performance
> goes way down.
>
> I can't tell what's causing those link-state changes.  It _looks_ like
> what you would get if there was an intermittent electrical connection
> causing random voltage fluctuations.  Whatever the cause is, plugging
> in the memory stick does seem to suppress those changes; they don't
> show up at all in the "working" trace.
>
> In theory, turning off power to port 4 might stop all the events from
> being reported.  You can try this to see if it works:
>
> 	echo 1 >/sys/bus/usb/devices/2-0:1.0/usb2-port4/disable
>
> Alan Stern

Thank you, that is very helpful, for a couple of reasons.

"Machine 2" is a new build, so if (as it sounds) the motherboard has a 
hardware problem, then I need to
look into returning it.

BTW- it seems I spoke too soon about the USB stick suppressing the 
error. After a couple of reboots with
it in place the problem re-occurred. It does seem that connecting a hub 
(switch) is the  only way
to reliably stop the error. The switch has a bunch of wiring connected 
to USB peripherals and other
machines. I would have guessed that might make the likelihood of picking 
up electrical noise
actually worse, but that seems not to be the case here.

"Machine 1" is several years old, it's actually the guts of the same PC 
that was upgraded to make M/c 2.
It's not usable, or sellable, with this performance hit happening. I 
have tried all the external USB ports
on this machine and not found the failing controller, my guess is it's 
going to be one that supports
some of the on-board USB headers.

I had been looking on the web for a way to shut down the problem port, 
or worst case the whole hub,
however all the Linux examples I found worked by either-

a) Preventing the loading of the driver for the chipset, by type. 
However that would kill all ports supported by
     the same type of controller, and this motherboard has multiple 
controllers of the same type onboard.

b) Shutting down a port by searching for the connected device 
identifier. However in these cases there
     _are_ no connected devlces, the fault happens when the controller 
is not connected to anything.

Hopefully the command you recommended will do the trick, I will let you 
know.

Would I be correct in thinking this would need to be run at every boot, 
some time after device enumeration,
or would it need to be run after every re-enumeration of devices after a 
USB device is connected /
disconnected? Not sure how to achieve that.

I very much appreciate your help in identifying the fault. Thank you.

Regards: C Evans

-- 

*Mr. C. J. Evans
Parkstone
Davis Street
Hurst
RG10 0TH

Tel: 0118 9340297
Mob: 07434 491984
*

Re: [PATCH v1] usb: core: fix pipe creation for get_bMaxPacketSize0

[Alan Stern]

On Sun, Mar 09, 2025 at 09:57:21PM +0000, Colin Evans wrote:
> > In theory, turning off power to port 4 might stop all the events from
> > being reported.  You can try this to see if it works:
> > 
> > 	echo 1 >/sys/bus/usb/devices/2-0:1.0/usb2-port4/disable
> > 
> > Alan Stern
> 
> Thank you, that is very helpful, for a couple of reasons.
> 
> "Machine 2" is a new build, so if (as it sounds) the motherboard has a
> hardware problem, then I need to
> look into returning it.
> 
> BTW- it seems I spoke too soon about the USB stick suppressing the error.
> After a couple of reboots with
> it in place the problem re-occurred. It does seem that connecting a hub
> (switch) is the  only way
> to reliably stop the error. The switch has a bunch of wiring connected to
> USB peripherals and other
> machines. I would have guessed that might make the likelihood of picking up
> electrical noise
> actually worse, but that seems not to be the case here.

It may have something to do with whether the attached device is USB-3 or 
USB-2.  Hubs are both (or are USB-2 only).

> "Machine 1" is several years old, it's actually the guts of the same PC that
> was upgraded to make M/c 2.
> It's not usable, or sellable, with this performance hit happening. I have
> tried all the external USB ports
> on this machine and not found the failing controller, my guess is it's going
> to be one that supports
> some of the on-board USB headers.

In fact, the port in question might not be attached to anything, or 
improperly grounded, or something like that.

> I had been looking on the web for a way to shut down the problem port, or
> worst case the whole hub,
> however all the Linux examples I found worked by either-
> 
> a) Preventing the loading of the driver for the chipset, by type. However
> that would kill all ports supported by
>     the same type of controller, and this motherboard has multiple
> controllers of the same type onboard.
> 
> b) Shutting down a port by searching for the connected device identifier.
> However in these cases there
>     _are_ no connected devlces, the fault happens when the controller is not
> connected to anything.
> 
> Hopefully the command you recommended will do the trick, I will let you
> know.
> 
> Would I be correct in thinking this would need to be run at every boot, some
> time after device enumeration,
> or would it need to be run after every re-enumeration of devices after a USB
> device is connected /
> disconnected? Not sure how to achieve that.

At every boot.  It doesn't have to be after all the other devices 
are enumerated; after the USB controller itself is enumerated will be 
good enough.

> I very much appreciate your help in identifying the fault. Thank you.

You're welcome.

Alan Stern