[Bug 213839] New: XHCI 7 port usb hub does not work correctly

[Bug 213839] New: XHCI 7 port usb hub does not work correctly

[bugzilla-daemon]

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: drivers_usb@kernel-bugs.kernel.org
          Reporter: tmezzadra@gmail.com
        Regression: No

I 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?

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213839

--- Comment #1 from Alan Stern (stern@rowland.harvard.edu) ---
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?

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213839

--- Comment #2 from tomas m (tmezzadra@gmail.com) ---
(In reply to Alan Stern from comment #1)
> 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

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213839

--- Comment #3 from Alan Stern (stern@rowland.harvard.edu) ---
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.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213839

ST (stulluk@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stulluk@gmail.com

--- Comment #4 from ST (stulluk@gmail.com) ---
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.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213839

Jonathan McDowell (noodles@earth.li) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |noodles@earth.li

--- Comment #5 from Jonathan McDowell (noodles@earth.li) ---
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.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213839

--- Comment #7 from Jonathan McDowell (noodles@earth.li) ---
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

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213839

--- Comment #8 from Jonathan McDowell (noodles@earth.li) ---
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

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213839

--- Comment #9 from Jonathan McDowell (noodles@earth.li) ---
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.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213839

--- Comment #10 from Alan Stern (stern@rowland.harvard.edu) ---
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.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213839

--- Comment #11 from Jonathan McDowell (noodles@earth.li) ---
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.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213839

--- Comment #12 from Jonathan McDowell (noodles@earth.li) ---
Created attachment 300193
  --> https://bugzilla.kernel.org/attachment.cgi?id=300193&action=edit
dmesg, no usb autosuspend, hub working

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213839

--- Comment #13 from Jonathan McDowell (noodles@earth.li) ---
Created attachment 300194
  --> https://bugzilla.kernel.org/attachment.cgi?id=300194&action=edit
dmesg, usb autosuspend, usb_snoop, hub not working

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213839

--- Comment #14 from Jonathan McDowell (noodles@earth.li) ---
Created attachment 300195
  --> https://bugzilla.kernel.org/attachment.cgi?id=300195&action=edit
dmesg, usb autosuspend, 2 drives, working

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213839

--- Comment #15 from Alan Stern (stern@rowland.harvard.edu) ---
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.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213839

--- Comment #16 from Jonathan McDowell (noodles@earth.li) ---
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.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213839

--- Comment #17 from Jonathan McDowell (noodles@earth.li) ---
(In reply to Jonathan McDowell from comment #16)
> 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!

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213839

--- Comment #18 from Alan Stern (stern@rowland.harvard.edu) ---
Good news!  I have posted the patch on the linux-usb mailing list; it should
get merged sometime in the next few weeks.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.