Different speed of USB control transfers for HS USB devices depending on used USB port

Different speed of USB control transfers for HS USB devices depending on used USB port

[Christian Krause]

Hello USB maintainers,

I've seen the following unexpected behavior with respect to EP0
control transfers:

The speed of control transfers for HS devices varies quite much
depending on which USB port of a system is used. The problem can be
replicated on different systems with different chipsets and for any HS
device I have tested.

Here is a concrete example:
- mainboard: MSI B550 GAMING GEN3 (MS-7B86)
- Linux kernel: Fedora's 6.11.10-200 kernel

The mainboard has two AMD USB HCs:
02:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] 500 Series
Chipset USB 3.1 XHCI Controller
2f:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB
3.0 Host Controller

I have monitored the USB low-level transfers with a HW USB analyzer.

a) control transfers slow: HS device connected to back panel USB2.0 port (black)
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/10p, 480M
    |__ Port 010: Dev 042, If 0, Class=Mass Storage, Driver=usb-storage, 480M
- the USB transactions (SETUP, IN, OUT, ...) happen every millisecond
and there are 8 SOFs between each of them
- the USB analyzer shows the following transactions (e.g. for a
GetDescriptor transfer):
    - 8x SOF
    - SETUP transaction
    - 8x SOF
    - IN transaction
    - 8x SOF
(depending on the descriptor size more IN transactions interleaved with 8 SOFs:
    - IN transaction
    - 8x SOF
    ... )
    - OUT transaction

b) control transfers slow: HS device connected to back panel USB3.x (red)
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/10p, 480M
    |__ Port 001: Dev 043, If 0, Class=Mass Storage, Driver=usb-storage, 480M
- same behavior as a)

c) control transfers fast: HS device connected to back panel USB3 port (blue)
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 480M
    |__ Port 001: Dev 046, If 0, Class=Mass Storage, Driver=usb-storage, 480M
- there is only a single SOF between between the SETUP, IN and OUT transactions
- multiple IN transactions are combined in one frame (e.g. for larger
descriptors)
- the USB analyzer shows the following transactions (e.g. for a
GetDescriptor transfer):
    - 1x SOF
    - SETUP transaction
    - 1x SOF
    - IN transaction
(depending on the descriptor size more IN transactions without SOFs)
    - IN transaction
    - ... )
    - 1x SOF
    - OUT transaction

Note: The timing can best be seen with a HW USB analyzer. Monitoring
/dev/usbmonx with wireshark still gives a good indication in the "Time
from request" in the "USB URB" section: for cases a) and b) the time
would be 2-5ms and for case c) it would be < 1ms for a GetDescriptor
request of a simple HS USB stick.

The behavior of case a) or b) makes control transfers with larger data
stages approx. 50 times slower.

Is that behavior an expected HW limitation or does it point to some
kind of SW issue?

I'm happy to help debug the issue. If you want me to do any debugging
steps or provide any additional information, please let me know!


Best regards,
Christian

Re: Different speed of USB control transfers for HS USB devices depending on used USB port

[Michał Pecio]

Hi,

I see obvious pattern that the bad ports are bus 001 and the good port
is bus 003, and they are two different chips.

Do you see similar correlation with chip types on other motherboards?

You can see the mapping between bus numbers and controllers using
ls -l /sys/bus/usb/devices/usb*

Generally, with xHCI it's on the controller to packetize and schedule 
such transfers, so this is likey a hardware problem.

Regards,
Michal

Re: Different speed of USB control transfers for HS USB devices depending on used USB port

[Christian Krause]

Hi Michal,

On Mon, Dec 9, 2024 at 11:03 PM Michał Pecio <michal.pecio@gmail.com> wrote:
> I see obvious pattern that the bad ports are bus 001 and the good port
> is bus 003, and they are two different chips.
>
> Do you see similar correlation with chip types on other motherboards?

Yes. Here's the result of my test:

HCs which show the problem:
Advanced Micro Devices, Inc. [AMD] 400 Series Chipset USB 3.1 xHCI
Compliant Host Controller [1022:43d5] (rev 01)
Advanced Micro Devices, Inc. [AMD] 500 Series Chipset USB 3.1 XHCI
Controller [1022:43ee]
Advanced Micro Devices, Inc. [AMD] 600 Series Chipset USB 3.2
Controller [1022:43f7] (rev 01)

HCs which don't show the problem:
Advanced Micro Devices, Inc. [AMD] Device [1022:15b6]
Advanced Micro Devices, Inc. [AMD] Device [1022:15b7]
Advanced Micro Devices, Inc. [AMD] Device [1022:15b8]
Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller [1022:149c]
Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller
[8086:a36d] (rev 10)

The tests were done without any external hubs.

> Generally, with xHCI it's on the controller to packetize and schedule
> such transfers, so this is likey a hardware problem.

Sounds plausible. On one of the systems I also booted Windows and I
observed exactly the same issue.

Since most USB devices use control requests mainly for the enumeration
with quite small data sizes, the problem is typically not visible.

I stumbled over the issue when using DFU (Device Firmware Upgrade).
DFU does all data transfer via control requests and so any larger data
transfer with the problematic HCs is about 50 times slower.

I'm open for any suggestions on how to proceed from here.

Best regards,
Christian