USB 3.0 running at USB 2.0 speeds

[phenest]

This is a tower with 2 rear facing USB 3.0 ports which are running at USB 3.0 speeds (5000M), but the 2 front facing ports are running at USB 2.0 speeds (480M).

I thought of checking BIOS settings, but given that both rear and front ports are using the same chipset and driver, that wouldn't make any difference. The only BIOS settings for USB are for USB Legacy support, USB 3.0 Legacy support, and EHCI hand-off, and I don't think any of that is related.

The only kernel parameter I've tried is iommu=soft and somewhere I found a suggestion for pci=nomsi but I haven't tested it.

Another possibility I found is that there's been a change in the kernel driver in the past that perhaps fixed a (not necessarily related) bug which caused this one. It may of happened sometime between Wheezy and Jessie, and has affected (apparently) other distros such as Ubuntu and Linux Mint. I have a spare hard drive, so I will try installing Wheezy and the Jessie and report the results.

uname -a

Code: Select all

Linux debian 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2 (2017-06-12) x86_64 GNU/Linux

lspci -k | grep -iEA3 usb

Code: Select all

00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Kernel driver in use: ehci-pci
	Kernel modules: ehci_pci
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Kernel driver in use: ehci-pci
	Kernel modules: ehci_pci
04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)
	Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci
06:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)
	Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci

lsusb -t

Code: Select all

/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
        |__ Port 1: Dev 8, If 4, Class=Vendor Specific Class, Driver=qmi_wwan, 480M
        |__ Port 1: Dev 8, If 2, Class=Mass Storage, Driver=usb-storage, 480M
        |__ Port 1: Dev 8, If 0, Class=Vendor Specific Class, Driver=option, 480M
        |__ Port 1: Dev 8, If 3, Class=Vendor Specific Class, Driver=option, 480M
        |__ Port 1: Dev 8, If 1, Class=Vendor Specific Class, Driver=option, 480M
        |__ Port 7: Dev 4, If 0, Class=Wireless, Driver=btusb, 12M
        |__ Port 7: Dev 4, If 1, Class=Wireless, Driver=btusb, 12M
        |__ Port 8: Dev 5, If 0, Class=Hub, Driver=hub/3p, 480M
            |__ Port 3: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
            |__ Port 3: Dev 7, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
            |__ Port 2: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M

dmesg | grep -i usb (snippet)

Code: Select all

[    1.459390] ACPI: bus type USB registered
[    1.459429] usbcore: registered new interface driver usbfs
[    1.459442] usbcore: registered new interface driver hub
[    1.459474] usbcore: registered new device driver usb
[    1.460046] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.461526] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 1
[    1.461952] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    1.461954] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.461955] usb usb1: Product: xHCI Host Controller
[    1.461957] usb usb1: Manufacturer: Linux 4.9.0-3-amd64 xhci-hcd
[    1.461958] usb usb1: SerialNumber: 0000:04:00.0
[    1.462122] hub 1-0:1.0: USB hub found
[    1.462268] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 2
[    1.465573] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[    1.465601] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[    1.465603] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.465605] usb usb2: Product: xHCI Host Controller
[    1.465606] usb usb2: Manufacturer: Linux 4.9.0-3-amd64 xhci-hcd
[    1.465608] usb usb2: SerialNumber: 0000:04:00.0
[    1.465775] hub 2-0:1.0: USB hub found
[    1.465995] xhci_hcd 0000:06:00.0: new USB bus registered, assigned bus number 3
[    1.466425] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
[    1.466427] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.466429] usb usb3: Product: xHCI Host Controller
[    1.466430] usb usb3: Manufacturer: Linux 4.9.0-3-amd64 xhci-hcd
[    1.466432] usb usb3: SerialNumber: 0000:06:00.0
[    1.466575] hub 3-0:1.0: USB hub found
[    1.466715] xhci_hcd 0000:06:00.0: new USB bus registered, assigned bus number 4
[    1.469583] usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.
[    1.469604] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
[    1.469605] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.469607] usb usb4: Product: xHCI Host Controller
[    1.469608] usb usb4: Manufacturer: Linux 4.9.0-3-amd64 xhci-hcd
[    1.469609] usb usb4: SerialNumber: 0000:06:00.0

[phenest]

I think this is a hardware quirk. There is a work-around:

With the PC powered off, plug in the USB 3.0 device into a front port and turn on the PC. The front USB 3.0 port is now 5000M, and the device is 5000M. But now, one of the rear facing ports is only USB 2.0. If I unplug the device from the front port and plug it into the same port, it now connects as USB 2.0 via a different bus.

It turns out Windows 10 has the same problem. I'm going to contact ASUS. Maybe there is a firmware update.

[v&n]

[DISCLAIMER : What is written below is my personal reading and interpretation of USB controllers, and may be partially or entirely wrong. It may be considered an 'educated guess' at best.]

I think this is a hardware quirk..

As far as I know, this is by design. Unless there are separate USB 2 ports available externally, connected to separate USB 2 controllers, the given USB 3 ports must be connected to controllers that have both USB2 and USB3 controllers integrated into one chip, with built-in switching circuits to switch between them as required. Depending on which of the ports detect a higher speed device first, they will internally get connected to the higher speed circuit. The remaining ports will then get connected to the built-in lower speed circuit. This kind of design was meant for backward compatibility, but can be hacked to supports more ports than the chip was originally supposed to support simultaneously (the *additional ports* working at the lower speed).

This is nothing new. This behaviour exists in (some, probably most) motherboards since USB 2 was introduced (to switch between USB 2/1 circuits). To understand this better, you can look at any popular USB 2 controller chip's datasheet and block diagram. They are all backward compatible with USB 1, by providing built-in USB 1 circuits, and automatic switching circuits to internally switch between them. (not sure if USB3 chip datasheets are available now or not. It wasn't at that time I was looking. It was also the time when there was only one manufacturer of USB3 chips). My common sense suggests only two ways to make all the available ports work simultaneously at the highest speed they support :

1) Either provide only as many ports as the controller can support at higher speed, or,
2) Use more than one controller, as many as needed to *properly* support all the provided ports at their higher speed (including internal ports and internally connected devices).

In both conditions, the ports can still be backwards compatible, and this is exactly what is done in motherboards that don't do the 'cheap tricks'.

Unfortunately, there seems no fixed rule or tradition (even the 'cheaper' and 'expensive' discrimination is not a sufficient condition) to predict or calculate how many available ports will actually work at the highest speed they support at any given time. So far, I have only been able to *guess* it AFTER observing the lsusb output and the actual behaviour.

Taking number of USB ports available on a motherboard including the internal ones and internally connected devices (like wifi cards attached to USB bus in some laptops), and looking at the 'lsusb -t' output, we can calculate the *max possible* USB3 ports the motherboard *should* be able to provide any given time. But even that does not mean they *must* be accessible all the time. I am not very sure whether it is due to hardware design or just a dirty marketing strategy (most of us tend to believe the latter, and not without reason), but it is not uncommon for a motherboard to NOT use all its potential capacity.

For example, the USB 3 chip in my laptop (Asus X54C) supports 2 simultaneous USB3 connections (I confirmed this by looking at the chip's datasheet once). But it has only one USB3 port (the only other available port is a USB2 port, connected to a separate USB2 controller chip). The same USB3 chip does provide the two expected USB3 ports in their more expensive models (featuring 2xUSB3 + 1xUSB2 port). Guess why - The more expensive model(s) have this additional port as their extra *feature* (besides a few other not-too-attractive perks) to justify the higher cost.

Another similar trick that I suspect vendors use to save on USB controller chips :

Even in some expensive HP premium model laptops, I have consistently observed a behaviour which makes me suspect that most (if not all) their 4 USB port models have only 3 ports connected to separate controllers, and one is connected via an internal shared hub. This causes this last port to interfere with the other port that it shares the connection with. It means possible disconnection (usually only momentarily) of the device on that 3rd port as soon as a 4th device is connected. While this may happen due to momentary power drop on that 3rd port, I have observed this happening even if the 4th device is a mouse or a thumb drive, thus strengthening my suspicion of a 'shared hub' behind the scene.

The manufacturers seem to take advantage of the fact that most of the users don't use all the USB ports at the same time. And even when they do, rarely do they notice 'minor' glitches or speed issues like this. Thus this kind of discrepancy goes unnoticed most of the time.

Last, please forgive me if the post went unnecessarily long and confusing. Continuous disturbance during these 'working hours' (yeah!) never allows me to concentrate on stuff like this. The topic was so provoking that I just couldn't stop myself from sharing what I have learnt (or guessed?) the hard way.

<phew!!>