Introduction
This page is intended for Linux users, as the potential problems it addresses are much less relevant for Windows computers: This is because less reputed USB controller vendors release flawed devices with workarounds implemented in their driver for Windows only, so Windows users are covered and need usually not to be aware of which hardware is used. Linux users, on the other hand, are exposed to these hardware bugs, and may therefore need to select their hardware carefully.
As the host USB controller’s quality significantly influences the behavior of the USB link, it’s important to detect its vendor and product IDs properly. This can get tricky, in particular if on a motherboard that has more than one type of USB controller, with some physical USB ports connected to one, and some to the other. This is not an unusual situation, in particular for computers that support recently released versions of the USB 3.x protocol: The cutting-edge revision is often supported by virtue of a dedicated chipset. Such chipsets tend to be problematic, since their main purpose is to add merits to the motherboard’s spec, so even less reputed brands may be used.
A utility is provided for use along with the XillyUSB IP core for the purpose of detecting the host controller in use: It prints out the path from the host’s USB controller to the XillyUSB device, showing the identification information for each component on the way.
It also prints out system information and an excerpt from the kernel log, consisting of kernel messages that mention the USB components on the path and all those containing the “XillyUSB” word. This part is useful for remote analysis, in particular when getinfo’s output is redirected to a file, for submission along with a request for assistance.
Execution
For execution, extract the getinfo.pl Perl script in the xillyusb.tar.gz bundle, found under utils/. From the directory it was uncompressed into, type
$ ./getinfo.pl
Identification of host controller
For the purpose of determining the USB path, only the first part is relevant. For example, with a Renesas USB controller, it can look like this:
Connection of USB device: 4-1 =================================================== USB Host controller: PCI ID 1912:0015 Renesas Technology Corp.: uPD720202 USB 3.0 Host Controller Linux driver: xhci_hcd
The first two lines under the title identify the PCI/PCIe device in use: The first line displays the Vendor and Product IDs in hex format, and the second is an attempt to translate this information into human readable format for convenience, based upon the pci.ids file on the computer that the script runs on.
The information in the second line is hence not fetched from the hardware nor the driver infrastructure, and a failure to resolve the IDs indicates nothing about the functionality nor support of the controller.
The crucial piece of information is the Vendor and Product IDs, which determine the identity of the USB controller. The behavior of the USB link depends to a large extent on this.
The Linux driver in use is also displayed. It’s very likely to be the kernel’s own xhci_hcd driver, since the vast majority of USB 3.x host controllers are designed to conform to the xHCI specification regarding their interface with the processor. A different driver may indicate an inherently problematic host controller (as it can’t be supported by the regular driver).
The USB path
The next part shows the path from the USB controller to the device, including these two components. For a direct connection between the host controller and the device, it will look something like this:
Path from USB root hub to device:
--- USB Hub element: 1d6b:0003
Manufacturer: Linux 5.7.0-test xhci-hcd
Product: xHCI Host Controller
--- USB Device: 10ee:ebbe
Manufacturer: Xillybus Ltd
Product: XillyUSB FPGA interface for USB 3.0
The first element is the root hub, which is the USB host controller. If Linux’ own kernel driver is used for the host controller (which is most likely the case), the Vendor / Product IDs are 1d6b:0003 (Linux Foundation 3.0 root hub) as shown above.
The second element is the device itself, the XillyUSB IP core inside the FPGA.
If there are any USB hubs between the host controller and the device, they are listed between the two elements shown above. Sometimes a physical hub appears as more than one element in the path, showing internal routing.
The XillyUSB IP core fully supports connection through a hub, including the special treatment of low-power states, however certain combinations of low-quality hubs and host USB controllers may cause problems.
System information and kernel logs
As mentioned above, the USB connection path is followed by system information which is obtained from various sources. It might be beneficial to pay attention to this part as well, in particular to the kernel version and the log messages. That said, it’s common to see error messages from the xhci-hcd driver even under proper operation: Many USB controllers that work perfectly from a practical point of view, may divert from the standard regarding their interface with the processor. This is even more common when the device is unplugged in the middle of busy traffic.
The kernel’s xhci-hcd driver is updated continuously by its maintainers to cope with the issues that cause these log messages, so different kernel version may display different log messages. This may and may not mean that the controller performs differently with different kernel versions.
USB controllers: The good and the bad
Once again, this is relevant for Linux users only. Windows drivers ensure that all USB host controllers on decent motherboards work properly, or they wouldn't be used.
There are a lot of motherboard I/O chipsets as well as dedicated components that provide host USB 3.x controller functionality, and it’s impossible to test each and every one. This is a partial list of accumulated knowledge, to be taken with a grain of salt:
- Recommended: NEC / Renesas uPD720202 chipset (PCI ID 1912:0015). It’s a standalone PCIe USB 3.0 controller which is widely available as PCIe cards for installation in standard PCs.
- Stay away: ASMedia USB controllers (PCI Vendor ID 1b21). There’s a range of standalone PCIe USB 3.x controllers from this brand, however they have displayed buggy behavior that leads to lockups and data errors in anything but trivial data exchange scenarios. These devices are found in standalone PCIe cards, but are also common on motherboards, possibly side by side with the companion I/O chipset’s USB controller. In the latter case, the motivation is typically to support protocols higher than USB 3.0, by connecting some USB ports to the ASMedia controller and some to the I/O chipset. The utility presented on this page helps telling which is which.
- Pick only recent: Intel’s companion I/O chipsets. The quality of the USB controllers in these chipsets seems to improve with time. It’s recommended to use chipsets released in 2017 or later, as a rough guideline.
