6 ms·

The unstated is that the core problem here (lack of USB2 on a USB3 connector) is _NOT_ standard. This is generally only a problem on the plethera of shit arm/et

The unstated is that the core problem here (lack of USB2 on a USB3 connector) is _NOT_ standard. This is generally only a problem on the plethera of shit arm/etc SoCs using garbage IP where the vendor is only interested in checking a box, than actually providing a working/compliant implementation of the specification. Part two of this problem are the USB2 implementations that don't provide USB1 Transaction Translators (TT), so keyboards/etc won't work. And as a 3rd note, the Pi4 actually has good USB3 because its implemented by a 3rd party XHCI controller like one might find on a random PCIe card. Combined with a usb3 hub with multiple TT's it should be possible to attach a number of SDR's etc at reasonable rates. Good luck figuring this out from the usb3 hub details unless it lists the chip its using.

de_Selby 5y ago
>The unstated is that the core problem here (lack of USB2 on a USB3 connector) is _NOT_ standard. It does say this at the end of the article.
MayeulC 5y ago
> the core problem here (lack of USB2 on a USB3 connector) Not sure if that's the core issue here? That's one of the issues, but there are more uses for that chip, like the introduction that hints at sharing USB3 bandwidth between multiple USB2 devices.
- dsr_ 5y ago
  Yeah, this. A person not familiar with this situation would think that if a USB3 hub had USB2 ports on it, it would do packet level buffering and switching so that the 5-10Gb/s of the USB3 upstream would be shared among the 480Mb/s USB2 ports. It should be reasonable to get 8-10 USB2 ports all operating at their maximum bandwidth off of 1 USB3 port. After all, that's how Ethernet works.
  - marcan_42 5y ago
    And the reason why that doesn't and can't work with USB2 is because, unlike Ethernet, USB is extremely closely tied to its physical layer and you cannot actually buffer and switch USB packets at all (without cooperation from at least one side). All communications are host-driven and stateful, and the timeouts for replies are on the order of single-digit microseconds, and the receiving end has no obligation to accept data, so there is no way to safely buffer data and forward it at a later time because that time might never come, and the mere act of accepting data from one end desyncs both ends' ideas of what data was successfully transferred, which can have higher level protocol implications. USB is a clusterfuck of a standard.
cma 5y ago
>Good luck figuring this out from the usb3 hub details unless it lists the chip its using. Any recommended hubs with the right chip?
mise_en_place 5y ago
XHCI is extremely buggy on Linux with recent stable kernel versions. For example I plug in a USB3 DAC into front panel, and all my USB devices shut off. XHCI will spew error msgs in dmesg during this.
- CyberRabbi 5y ago
  TBH that sounds like your hardware is bad. I’ve had issues like this and when I did the tcpdump of the usb traffic (using usbmon), the hardware is always malfunctioning in response to correct messages sent by the kernel.
  - marcan_42 5y ago
    You cannot diagnose/debug host controller hardware/driver issues with usbmon. It does not work at a low enough layer. It's only good for debugging issues with downstream devices. You also cannot tell whether certain problems are the host controller's fault or the downstream device's fault with it. You need a physical USB protocol analyzer that works at the packet level for that (usbmon works at the transaction level).
    - CyberRabbi 5y ago
      That’s exactly my point. The OP claimed that the kernel’s XHCI support is faulty, usbmon will rule that out.
      - marcan_42 5y ago
        It won't, because you can't know if the misbehavior is caused by a device or the host controller when you're looking behind the host controller. Everything you see in usbmon is influenced by both. And besides, a malfunctioning device can't cause your entire USB controller to bork; that indicates a bug in the USB controller or its driver by definition, making usbmon inherently unreliable in that scenario.
        5y ago

de_Selby 5y ago

>The unstated is that the core problem here (lack of USB2 on a USB3 connector) is _NOT_ standard. It does say this at the end of the article.

MayeulC 5y ago

> the core problem here (lack of USB2 on a USB3 connector) Not sure if that's the core issue here? That's one of the issues, but there are more uses for that chip, like the introduction that hints at sharing USB3 bandwidth between multiple USB2 devices.

dsr_ 5y ago
Yeah, this. A person not familiar with this situation would think that if a USB3 hub had USB2 ports on it, it would do packet level buffering and switching so that the 5-10Gb/s of the USB3 upstream would be shared among the 480Mb/s USB2 ports. It should be reasonable to get 8-10 USB2 ports all operating at their maximum bandwidth off of 1 USB3 port. After all, that's how Ethernet works.
- marcan_42 5y ago
  And the reason why that doesn't and can't work with USB2 is because, unlike Ethernet, USB is extremely closely tied to its physical layer and you cannot actually buffer and switch USB packets at all (without cooperation from at least one side). All communications are host-driven and stateful, and the timeouts for replies are on the order of single-digit microseconds, and the receiving end has no obligation to accept data, so there is no way to safely buffer data and forward it at a later time because that time might never come, and the mere act of accepting data from one end desyncs both ends' ideas of what data was successfully transferred, which can have higher level protocol implications. USB is a clusterfuck of a standard.

cma 5y ago

>Good luck figuring this out from the usb3 hub details unless it lists the chip its using. Any recommended hubs with the right chip?

mise_en_place 5y ago

XHCI is extremely buggy on Linux with recent stable kernel versions. For example I plug in a USB3 DAC into front panel, and all my USB devices shut off. XHCI will spew error msgs in dmesg during this.

CyberRabbi 5y ago
TBH that sounds like your hardware is bad. I’ve had issues like this and when I did the tcpdump of the usb traffic (using usbmon), the hardware is always malfunctioning in response to correct messages sent by the kernel.
- marcan_42 5y ago
  You cannot diagnose/debug host controller hardware/driver issues with usbmon. It does not work at a low enough layer. It's only good for debugging issues with downstream devices. You also cannot tell whether certain problems are the host controller's fault or the downstream device's fault with it. You need a physical USB protocol analyzer that works at the packet level for that (usbmon works at the transaction level).
  - CyberRabbi 5y ago
    That’s exactly my point. The OP claimed that the kernel’s XHCI support is faulty, usbmon will rule that out.
    - marcan_42 5y ago
      It won't, because you can't know if the misbehavior is caused by a device or the host controller when you're looking behind the host controller. Everything you see in usbmon is influenced by both. And besides, a malfunctioning device can't cause your entire USB controller to bork; that indicates a bug in the USB controller or its driver by definition, making usbmon inherently unreliable in that scenario.
      - 5y ago