Re: [gentoo-user] Re: new USB question

[Jack]

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