usb: core: fix pipe creation for get_bMaxPacketSize0

From: Stefan Eichenberger <[email protected]>

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.

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

index c3f839637cb5..59e38780f76d 100644
@@ -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

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.

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

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

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-

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?

The differences may not matter if they use similar hardware components.

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?

...

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

Ah -- you have to load the usbmon module first:

modprobe usbmon

Some distributions do this for you automatically.

Alan Stern

On 06/03/2025 21:43, Alan Stern wrote:

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 *

/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M

    |__ Port 004: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 002: Dev 004, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 002: Dev 004, If 1, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 003: Dev 014, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 001: Dev 018, If 0, Class=Human Interface Device, Driver=usbhid, 12M
            |__ Port 001: Dev 018, If 1, Class=Human Interface Device, Driver=usbhid, 12M
            |__ Port 002: Dev 022, If 0, Class=Audio, Driver=snd-usb-audio, 12M
            |__ Port 002: Dev 022, If 1, Class=Audio, Driver=snd-usb-audio, 12M
            |__ Port 002: Dev 022, If 2, Class=Human Interface Device, Driver=usbhid, 12M
            |__ Port 003: Dev 025, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 004: Dev 017, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 001: Dev 021, If 0, Class=Video, Driver=uvcvideo, 480M
            |__ Port 001: Dev 021, If 1, Class=Video, Driver=uvcvideo, 480M
            |__ Port 001: Dev 021, If 2, Class=Audio, Driver=snd-usb-audio, 480M
            |__ Port 001: Dev 021, If 3, Class=Audio, Driver=snd-usb-audio, 480M
    |__ Port 005: Dev 003, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 001: Dev 006, If 0, Class=Audio, Driver=snd-usb-audio, 12M
        |__ Port 001: Dev 006, If 1, Class=Audio, Driver=snd-usb-audio, 12M
        |__ Port 001: Dev 006, If 2, Class=Audio, Driver=snd-usb-audio, 12M
        |__ Port 001: Dev 006, If 3, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 003: Dev 009, If 0, Class=Hub, Driver=hub/4p, 480M
    |__ Port 010: Dev 005, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 002: Dev 008, If 0, Class=Mass Storage, Driver=usb-storage, 480M
    |__ Port 011: Dev 007, If 0, Class=Hub, Driver=hub/4p, 480M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/5p, 20000M/x2
    |__ Port 005: Dev 002, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 003: Dev 003, 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
/:  Bus 005.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/:  Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 001: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 12M
/:  Bus 008.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/0p, 5000M
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
    |__ Port 005: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 001: Dev 004, If 0, Class=Audio, Driver=snd-usb-audio, 12M
        |__ Port 001: Dev 004, If 1, Class=Audio, Driver=snd-usb-audio, 12M
        |__ Port 001: Dev 004, If 2, Class=Audio, Driver=snd-usb-audio, 12M
        |__ Port 001: Dev 004, If 3, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 003: Dev 007, If 0, Class=Hub, Driver=hub/4p, 480M
    |__ Port 010: Dev 003, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 002: Dev 006, If 0, Class=Mass Storage, Driver=usb-storage, 480M
    |__ Port 011: Dev 005, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 001: Dev 008, If 0, Class=Mass Storage, Driver=usb-storage, 480M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/5p, 20000M/x2
    |__ Port 005: Dev 012, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 003: Dev 013, 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
/:  Bus 005.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
    |__ Port 002: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 002: Dev 003, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 002: Dev 003, If 1, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 003: Dev 004, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 001: Dev 006, If 0, Class=Human Interface Device, Driver=usbhid, 12M
            |__ Port 001: Dev 006, If 1, Class=Human Interface Device, Driver=usbhid, 12M
            |__ Port 002: Dev 008, If 0, Class=Audio, Driver=snd-usb-audio, 12M
            |__ Port 002: Dev 008, If 1, Class=Audio, Driver=snd-usb-audio, 12M
            |__ Port 002: Dev 008, If 2, Class=Human Interface Device, Driver=usbhid, 12M
            |__ Port 003: Dev 009, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 004: Dev 005, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 001: Dev 007, If 0, Class=Video, Driver=uvcvideo, 480M
            |__ Port 001: Dev 007, If 1, Class=Video, Driver=uvcvideo, 480M
            |__ Port 001: Dev 007, If 2, Class=Audio, Driver=snd-usb-audio, 480M
            |__ Port 001: Dev 007, If 3, Class=Audio, Driver=snd-usb-audio, 480M
/:  Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    |__ Port 002: Dev 002, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 003: Dev 003, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 004: Dev 004, If 0, Class=Hub, Driver=hub/4p, 5000M
/:  Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 001: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 12M
/:  Bus 008.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/0p, 5000M

85,085 lines not shown · raw message

Part of this message is not shown here. View the raw message.

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

into one

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
*

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

In fact, the port in question might not be attached to anything, or improperly grounded, or something like 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.

You're welcome.

Alan Stern