Bottom line - as far as I can tell, the motherboard and software are
actually all behaving correctly, if confusingly. Details below.
On 2020.10.06 00:45, Sid Spry wrote:
On Mon, Oct 5, 2020, at 1:33 PM, Jack wrote:
> Grant - thanks for the info.
>
I'm curious about the pairing by PCI device - it's not clear if the
every root_hub is a real controller, or not. The specs of the board
say USB2: two ports on the back and two USB2 headers (so I don't
know why it claims 10 ports instead of 6) and USB3: three type A and
one Type C ports on the back. Bus 2 is a bit of a mystery, as
although the B350 chipset presumably does have an enhanced
superspeed (3.1) controller, it is not available through the
motherboard. If bus 3 is the unavailable 3.1 controller, then is
bus 1 driven by the CPU or the chipset, and where is the other one?
So far, anything plugged into any of the front ports or rear USB2
ports shows up on bus 1, and anything plugged into the rear USB3
ports shows up on bus 3. I think my new USB flash drive is really
USB2 and not USB3 as advertised.
Logically I think the controllers are separate, but they are spawned
from the same device. On an ARM64 system there is a single DWC3
device per USB3/2 pair. Intel is moving to DesignWare's IP, and I
think existing platforms that split devices are similar. Additionally
the xHCI driver is now being used to drive all USB bus types.
Agreed. Under Linux, a single USB2/3 port shows up as two separate
ports, under separate hubs, but both mapped to the same controller.
Plug in a device, and it shows up on the hub for the speed of the
device. (We may have a terminology issue, but I'm calling the
controller the physical implementation in the CPU or chipset, and the
hub a more logical thing more based in the driver software.
If you want to test this you can unbind the driver from individual
PCIe devices. Check /sys/bus/pci/devices and see what disappears.
On a development board I see:
$ lsusb -t
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p,
480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p,
480M
And I happen to know the first 2 lines are the platform device at
fe900000. If I disable that device both disappear.
However, as I tried to describe earlier, on most x86 systems I have
used it is possible to actually plug a USB2 device into a port
associated with a USB3 root hub and the output would be rewritten as
such:
$ lsusb -t
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
Here, my current understanding is not that bus 6 will be rewritten to
show the slower speed, but that a true USB3 device plugged into that
port will show up on bus 6, and a USB2 device plugged into the same
port will show up on bus 5.
When all USB2 devices are removed the bus speed returns to 5000M.
I"m still guessing slightly, still not having a true USB 3.0 device to
test, but in my case, I don't think any hubs will switch speed. Two
hub/ports show up for each physical port.
I suspect you are encountering some variation of this. Can you unplug
absolutely everything and see the speeds reported by lsusb -t? Then,
plug things in and see if they change. If you've already done this my
apologies, it's kind of hard to find the text among all the dmesg.
No lines in libusb or libusb -t output change, only lines get
added/removed when plugging/unplugging anything. As I said, however,
my biggest problem now is that I don't actually have a real USB 3.0
device. The USB 3.0 flash drive I bought was simply a fraudulent
listing (already refunded) and the webcam seems to be internally
capable of SuperSpeed, but will never actually do so, since it's plug
is an old USB2 Type A plug, without the five extra connectors which
would carry the USB3 signale.
Later, I'll reboot into Windows to see what that shows, as MSI tech
support refuses to talk about Linux.
As much as I hate to have done so, running Microsoft's USB Viewer
finally made things click for me. That shows only two controllers,
both xHCI, and the IDs let me map them to what I see in Linux. One has
eight ports. Four of those ports are USB 3.0 only and the other four
are USB 1.1/2.0 - and they are listed as pairs of "companion ports."
On linux, each set of four shows up as a separate hub. These map to
the two USB3 headers, one of which is currently connected to the front
USB ports. All that comes from the CPU. the other controller shows
fourteen ports. The first eight are four pairs as with the other
controller. These are for the USB3 ports on the IP panel. (One of
these is Type_C, three are Type-A.) The remaining six ports are all
USB2 only, and are for the two USB2 ports on the back IO panel, and the
two USB2 headers on the motherboard. In linux, one bus shows the four
USB3 ports, and the other bus shows the four paired ports, plus the six
USB2 only ports/headers. Now that I understand it, it does make
sense. It just took an inordinate amount of work to figure it all out.
It may be worth pointing out the platform implements standards that
are divorced from the OS you are running. If it doesn't work with
both it can still be their problem.
It apparently does work correctly with both OS's, but each OS handles
the naming/grouping of ports differently. I think it would also have
been clearer to me earlier if I did have a real USB3 device to use.
Actually, I'm still not quite sure why dmesg/lsusb shows the CPU based
controller as 10000M speed instead of the expected 5000M, but as long
as it works at 5000M it is doing what it claims it will do.
Recently I had to do a differential test using Windows, assuming it'd
be more featureful. It is. But Windows has issues with device
enumeration. I am wondering if the original link speed problems (USB2
devices slowing down USB3 busses) was a Linux-specific issue, or if
it was just only visible to me on Linux.
I suspect to be absolutely sure about speeds, you would need to
actually test them. I've figured out how to test a flash drive with dd
on linux, but I'm not sure what the closest equivalent would be on
Windows. I'd guess you would need to test a USB3 device, both with and
without a USB2 device plugged into another port on the same bus.
I think I am encountering some variation of your problem, but mine is
even weirder. I have control over the device which is USB-C. In one
cable orientation it will enumerate with Windows, in the other it
will not. In that same orientation it will enumerate against an ARM64
system as USB3. In the other orientation it will enumerate against
ARM64/x86 systems as USB2. It seems to be unable to enumerate as a
USB3 device on Linux, but I need to do more testing.
I have no experience at all wtih Type-C cables, but I'd read up, as I
recall reading that not all Type-C cables are equivalent, and I can
imagine that if the cable it not really wired completely and correctly,
it could lead to that symptom.
A friend of mine reports he has a USB-C cable that is not reversible.
This may not be the cable's fault.
Then again, it might be.
So: Check your cable, and try more than one device. Also there may be
bugs in either the kernel's xhci drivers or new USB3 hardware.
In my case, no cables involved, other than those which are part of the
device, and as I said, my two supposed USB3 devices are both USB2 only.
I'd say "sorry for the noise" but I know I've learned some stuff from
all this.
Jack
