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,
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
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
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?
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-
- 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.
- 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?
- 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
linux-stable-mirror@lists.linaro.org
-
Alan Stern -
incansvl -
Stefan Eichenberger