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.
> 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.
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.
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.
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.
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.
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).
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.
Whether it’s the device or the host controller is irrelevant here. The OP claimed the fault was in the kernel’s XHCI implementation. Usbmon is enough To rule out the kernel in vast majority of instances. That is the subject of this thread. No one ever claimed usbmon can differentiate between errors in the host controller or device. “Hardware issue” includes both and does not include the kernel.
I don't know how you plan to tell apart kernel xHCI driver bugs from xHCI controller bugs with usbmon, which has nothing to do with the xHCI layer. It's at a higher layer. It doesn't show you anything related to xHCI internals. You can't know if any given behavior came from the HC or the kernel, what happened really, or anything else.
Source: I wrote the virtual xHCI implementation in QEMU (and worked around broken Windows drivers in it), I have experience with this.
I’d be willing to bet my life that the kernel’s more than a decade old and globally deployed XHCI implementation is not the cause of his USB issues.
Is it technically possible that usbmon will say that it sent proper data to the device when in fact it didn’t due to a bug in the kernel XHCI stack? Yes it is. Is it likely? very much not.
Usbmon was invented for this exact use case: debugging usb issues under the assumption that there is no fault in the kernel’s usb stack. It should be used before even considering a USB protocol analyzer. Basic intuition tells us it’s a hardware issue, either controller, hub, or device.
> I’d be willing to bet my life that the kernel’s more than a decade old and globally deployed XHCI implementation is not the cause of his USB issues.
I wouldn't, because I've found and fixed bugs in the kernel's xHCI implementation, and I still regularly panic or oops my kernel with dodgy USB devices, which is by definition a kernel bug (and a security one at that). USB is an overcomplicated standard and extremely difficult to implement properly.
> Is it technically possible that usbmon will say that it sent proper data to the device when in fact it didn’t due to a bug in the kernel XHCI stack? Yes it is. Is it likely? very much not.
As someone who works with USB regularly, I very much disagree with your assessment.
> Usbmon was invented for this exact use case: debugging usb issues under the assumption that there is no fault in the kernel’s usb stack.
Usbmon was invented for debugging USB issues with a single device, under the assumption that there is no fault with the kernel's USB stack and the controller. Once you're having controller-global issues that could be caused by either of those, usbmon is not useful because that assumption no longer holds.
> Basic intuition tells us it’s a hardware issue, either controller, hub, or device.
We clearly have very different intuitions here. I would absolutely split my bets on it being a controller or kernel issue.
> I still regularly panic or oops my kernel with dodgy USB devices
All intuition differences aside, if you are basing your intuition on whether a usb bug is in the kernel based on your experience dealing with dodgy devices, then shouldn’t your intuition agree with mine? Root cause tends to be dodgy hardware
The device is buggy and the kernel is buggy. The device is buggy because it did something stupid; the kernel is buggy because it crashed in response. That's two independent bugs. Sometimes it isn't even buggy devices, just devices disconnecting at the wrong time. I've crashed my kernel with things as simple as devices rapidly reconnecting or simply ceasing to respond/timing out.
Most of the kernel bugs around this are state/race issues. Device disappears in the middle of kernel code that doesn't have proper error recovery, boom. That's a kernel bug that applies in normal circumstances too, not just under an adversarial device model, because USB is designed to be hotpluggable at any time. Doesn't matter if the device disappeared because it crashed or because the user yanked the cable; it's just easier to reproduce with a crashy device. And the error recovery logic is notoriously hard to get right, which is why I'm not surprised the kernel is still buggy after all these years.
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.