New: XHCI 7 port usb hub does not work correctly
https://bugzilla.kernel.org/show_bug.cgi?id=213839
Bug ID: 213839
Summary: XHCI 7 port usb hub does not work correctly
Product: Drivers
Version: 2.5
Kernel Version: 5.13.4
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: USB
Assignee: [email protected]
Reporter: [email protected]
Regression: NoI got an off brand 7-port usb 2.0 which internally has two ICs.
first IC connected to the host's usb port exposes 3 USB ports. its 4th usb port has a second identical IC connected which exposes 4 USB ports making it a total of 7 USB 2.0 ports available.
Bus 002 Device 065: ID 0a05:7211 Unknown Manufacturer hub Bus 002 Device 064: ID 0a05:7211 Unknown Manufacturer hub
As they appear from lsusb
the problem is that the first chip works correctly (first 3 USB ports connected to it work). But as soon as I connect a usb device on any of the ports from the second chip. i get the following problems in dmesg:
[ 2215.717828] usb 2-1.1: new full-speed USB device number 29 using xhci_hcd [ 2215.808680] usb 2-1.1: New USB device found, idVendor=0a05, idProduct=7211, bcdDevice= 1.00 [ 2215.808685] usb 2-1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 2215.808688] usb 2-1.1: Product: USB2.0 HUB [ 2215.809333] hub 2-1.1:1.0: USB hub found [ 2215.809426] hub 2-1.1:1.0: 4 ports detected [ 2216.158062] usb 2-1.1: USB disconnect, device number 29 [ 2216.174608] usb 2-1.1-port3: attempt power cycle [ 2216.561173] usb 2-1.1: new full-speed USB device number 34 using xhci_hcd [ 2216.652346] usb 2-1.1: New USB device found, idVendor=0a05, idProduct=7211, bcdDevice= 1.00 [ 2216.652359] usb 2-1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 2216.652365] usb 2-1.1: Product: USB2.0 HUB [ 2216.654327] hub 2-1.1:1.0: USB hub found [ 2216.654480] hub 2-1.1:1.0: 4 ports detected [ 2217.001529] usb 2-1.1: USB disconnect, device number 34 [ 2217.017975] usb 2-1.1-port3: attempt power cycle [ 2217.404536] usb 2-1.1: new full-speed USB device number 39 using xhci_hcd [ 2217.495411] usb 2-1.1: New USB device found, idVendor=0a05, idProduct=7211, bcdDevice= 1.00 [ 2217.495417] usb 2-1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 2217.495419] usb 2-1.1: Product: USB2.0 HUB [ 2217.496120] hub 2-1.1:1.0: USB hub found [ 2217.496221] hub 2-1.1:1.0: 4 ports detected [ 2217.844888] usb 2-1.1: USB disconnect, device number 39 [ 2217.861345] usb 2-1.1-port3: attempt power cycle
and so on....
This same device at a Windows computer works correctly.
Ideas?
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213839] XHCI 7 port usb hub does not work correctly
https://bugzilla.kernel.org/show_bug.cgi?id=213839
--- Comment #1 from Alan Stern ([email protected]) --- This could easily be a power issue. Does either the 7-port hub or the device you plug into it have its own power source?
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213839] XHCI 7 port usb hub does not work correctly
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=213839
--- Comment #2 from tomas m ([email protected]) --- (In reply to Alan Stern from comment #1)
Quoted 2 lines
This could easily be a power issue. Does either the 7-port hub or the device you plug into it have its own power source?
I measured the 5v on both chips and its 5v sharp.
Soldered an additional cap to its vcc too.
Its the same vcc source.
Like i said. Under windows it works
It is being powered by the usb port.
I will test an external suppy just to be safe and report
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213839] XHCI 7 port usb hub does not work correctly
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=213839
--- Comment #3 from Alan Stern ([email protected]) --- Have you tried using Wireshark to capture the USB communications to/from the hub under both Windows and Linux for comparison? If there's a difference, it should show up.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213839] XHCI 7 port usb hub does not work correctly
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=213839
ST ([email protected]) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #4 from ST ([email protected]) ---
I have exactly the same device, it is sold as USB3.0, but I observe same behaviour ( detected as USB2.0) on all my computers. Tomorrow I will find a chance to try it on a Windows machine, and report back.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213839] XHCI 7 port usb hub does not work correctly
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=213839
Jonathan McDowell ([email protected]) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #5 from Jonathan McDowell ([email protected]) ---
I've just ended up with one of these devices and see the same behaviour; on Linux (5.10.70 from Debian) only 3 ports are operational, whereas when plugged into a Windows laptop all 7 ports work. It seems this is a knock-off hub - it was sold as 480Mb/s capable, but is only reporting itself as full-speed (12Mb/s).
As Tomas reports it shows up as 2 USB hubs - lsusb -vv output as follows:
Bus 003 Device 080: ID 0a05:7211 Unknown Manufacturer hub Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub bDeviceSubClass 0 bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 8 idVendor 0x0a05 Unknown Manufacturer idProduct 0x7211 hub bcdDevice 1.00 iManufacturer 0 iProduct 1 USB2.0 HUB iSerial 0 bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0019
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 255
Apparently the chip involved is a Micov MW7211 which is a single chip full-speed hub solution. I've no particular interest in seeing this work, given that it's not high-speed capable, but figured the additional information might be helpful as there's obviously some difference in the way Windows is driving the hub compared to Linux.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213839] XHCI 7 port usb hub does not work correctly
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=213839
--- Comment #7 from Jonathan McDowell ([email protected]) --- Created attachment 300189
--> https://bugzilla.kernel.org/attachment.cgi?id=300189&action=edit
Plugged in under Windows, USB flash drive inserted into port on second hub
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213839] XHCI 7 port usb hub does not work correctly
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=213839
--- Comment #8 from Jonathan McDowell ([email protected]) --- Created attachment 300190
--> https://bugzilla.kernel.org/attachment.cgi?id=300190&action=edit
Plugged in under Linux, USB flash drive inserted into port on second hub
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213839] XHCI 7 port usb hub does not work correctly
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=213839
--- Comment #9 from Jonathan McDowell ([email protected]) --- Attached files are hopefully helpful. Capture is started, hub is plugged in, USB3 flash drive is then plugged into a port off the second hub chip. In the Windows case it's detected fine (you can see the flurry of USB Mass Storage requests), in the Linux case there's some sort of disconnect/reconnect event but the flash drive never appears.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213839] XHCI 7 port usb hub does not work correctly
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=213839
--- Comment #10 from Alan Stern ([email protected]) --- So far I have only looked at the Linux trace. It shows two unusual things I don't understand.
One is that some process (I don't know which) re-reads the hub's device and configuration descriptors while the second device is being initialized, and apparently as a result of this the process decides to reset the hub. Why does this happen?
The second is that when the descriptors are re-read, the hub's config descriptor has changed! The original bmAttributes value is 0xe0, as shown in the lsusb output above. But the bmAttributes value in the trace is 0xc0; the changed bit is the flag for Wakeup support. Most likely this is a bug in the hub's firmware.
Perhaps additional debugging information will help. You can enable dynamic debugging and snooping for USB by doing:
echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control echo 1 >/sys/module/usbcore/parameters/usbfs_snoop
Clear the kernel log buffer by doing:
dmesg -C
Then plug in the hub and and plug in a device to one of the non-working ports. Let's see what the dmesg log shows after that.
Another unusual thing shows up clearly in the trace: The autosuspend_delay_ms time is set to a very low value; it looks like 20 ms. You might get better results leaving the delay set to its default value of 2 seconds. Or turn USB autosuspend off entirely by doing:
echo -1 >/sys/module/usbcore/parameters/autosuspend
before plugging in the hub.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213839] XHCI 7 port usb hub does not work correctly
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=213839
--- Comment #11 from Jonathan McDowell ([email protected]) --- Autosuspend appears to be the issue; if I disable it using the echo command provided then the additional ports on the hub work ok and the flash drive is detected.
Looking at my kernel config (this is Debian 11/bullseye, their stock 5.10.70-1 kernel) I see:
CONFIG_USB_AUTOSUSPEND_DELAY=2
Which according to drivers/usb/core/Kconfig is the default.
However hub_probe in drivers/usb/core/hub.c forces the suspend delay for a hub to 0ms as long as autosuspend is enabled.
As an experiment, theorising if the first hub chip didn't get put immediately to sleep devices off the 2nd hub chip would be seen, I tried plugging in the hub, plugging a flash drive into a port on the first chip (which is seen, as expected) and then plugging a flash drive into a port on the second chip (which would normally not be seen). Both drives are correctly detected.
I'll attach all 3 dmesgs now but it seems like the 0 delay in hub.c is what's causing the problem.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213839] XHCI 7 port usb hub does not work correctly
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=213839
--- Comment #12 from Jonathan McDowell ([email protected]) --- Created attachment 300193
--> https://bugzilla.kernel.org/attachment.cgi?id=300193&action=edit
dmesg, no usb autosuspend, hub working
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213839] XHCI 7 port usb hub does not work correctly
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=213839
--- Comment #13 from Jonathan McDowell ([email protected]) --- Created attachment 300194
--> https://bugzilla.kernel.org/attachment.cgi?id=300194&action=edit
dmesg, usb autosuspend, usb_snoop, hub not working
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213839] XHCI 7 port usb hub does not work correctly
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=213839
--- Comment #14 from Jonathan McDowell ([email protected]) --- Created attachment 300195
--> https://bugzilla.kernel.org/attachment.cgi?id=300195&action=edit
dmesg, usb autosuspend, 2 drives, working
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213839] XHCI 7 port usb hub does not work correctly
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=213839
--- Comment #15 from Alan Stern ([email protected]) --- Created attachment 300199
--> https://bugzilla.kernel.org/attachment.cgi?id=300199&action=edit
Mark child resume requests in hub->event_bits, not hub->change_bits
Congratulations on tracking this down. Later on I will send you a patch to disable autosuspend for these hubs, if it turns out to be needed. But for now, I'd like to track down the exact pathway for the problem, if you don't mind.
Can you test the attached patch? It looks like there is a bug in the hub driver's resume handler. When a resuming hub sees that one of its downstream ports got a resume request from a child device, it sets a corresponding bit in the hub->change_bits variable. But this variable is meant for connection changes, not suspend/resume status changes; which explains why the child hub ends up getting reset. The bit should be set in the hub->event_bits variable instead. (If you read through port_event() and hub_event(), you'll see how the two variables are handled similarly but not exactly the same.)
This bug wasn't noticed before because non-buggy devices don't change their descriptors, and hub_port_connect_change() is careful to check for cases where there wasn't a real connection change (i.e., device is still connected, port is still enabled, and device descriptors haven't changed). But your buggy hub does change its config descriptor and so it gets reset.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213839] XHCI 7 port usb hub does not work correctly
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=213839
--- Comment #16 from Jonathan McDowell ([email protected]) --- Excellent. Your fix appears to make things work fine. Built it on top of 5.12.12, plugged in the hub, plugged flash drive into a port off the second hub chip and it gets detected fine:
[ 64.055322] usb 1-1: new full-speed USB device number 2 using xhci_hcd [ 64.223348] usb 1-1: New USB device found, idVendor=0a05, idProduct=7211, bcdDevice= 1.00 [ 64.223357] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 64.223360] usb 1-1: Product: USB2.0 HUB [ 64.272644] hub 1-1:1.0: USB hub found [ 64.275305] hub 1-1:1.0: 4 ports detected [ 64.715299] usb 1-1.4: new full-speed USB device number 3 using xhci_hcd [ 64.843578] usb 1-1.4: New USB device found, idVendor=0a05, idProduct=7211, bcdDevice= 1.00 [ 64.843584] usb 1-1.4: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 64.843586] usb 1-1.4: Product: USB2.0 HUB [ 64.880662] hub 1-1.4:1.0: USB hub found [ 64.883305] hub 1-1.4:1.0: 4 ports detected [ 78.843353] usb 1-1.4.2: new full-speed USB device number 4 using xhci_hcd [ 78.982539] usb 1-1.4.2: not running at top speed; connect to a high speed hub [ 79.000617] usb 1-1.4.2: New USB device found, idVendor=0951, idProduct=1697, bcdDevice= 1.00 [ 79.000626] usb 1-1.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 79.000629] usb 1-1.4.2: Product: DT Ultimate G3 [ 79.000631] usb 1-1.4.2: Manufacturer: Kingston [ 79.000633] usb 1-1.4.2: SerialNumber: 0018F30C9F50BE5181712973 [ 79.013499] SCSI subsystem initialized [ 79.015328] usb-storage 1-1.4.2:1.0: USB Mass Storage device detected [ 79.015438] scsi host0: usb-storage 1-1.4.2:1.0 [ 79.015492] usbcore: registered new interface driver usb-storage [ 79.016658] usbcore: registered new interface driver uas [ 80.026221] scsi 0:0:0:0: Direct-Access Kingston DT Ultimate G3 PMAP PQ: 0 ANSI: 6 [ 80.029716] scsi 0:0:0:0: Attached scsi generic sg0 type 0 [ 80.032151] sd 0:0:0:0: [sda] 61407232 512-byte logical blocks: (31.4 GB/29.3 GiB) [ 80.033068] sd 0:0:0:0: [sda] Write Protect is off [ 80.033070] sd 0:0:0:0: [sda] Mode Sense: 2b 80 00 08 [ 80.033986] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 80.271640] sda: sda1 [ 80.275055] sd 0:0:0:0: [sda] Attached SCSI removable disk [ 82.061123] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts:
errors=remount-ro. Quota mode: none.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213839] XHCI 7 port usb hub does not work correctly
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=213839
--- Comment #17 from Jonathan McDowell ([email protected]) --- (In reply to Jonathan McDowell from comment #16)
Quoted 3 lines
Excellent. Your fix appears to make things work fine. Built it on top of 5.12.12, plugged in the hub, plugged flash drive into a port off the second hub chip and it gets detected fine:
Er, 5.15.12, i.e. latest stable, I didn't just pick a random kernel version to test!
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213839] XHCI 7 port usb hub does not work correctly
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=213839
--- Comment #18 from Alan Stern ([email protected]) --- Good news! I have posted the patch on the linux-usb mailing list; it should get merged sometime in the next few weeks.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.