Something does seem odd. However, it might just be the way the OTG (micro-USB) port is set up (explained further down). Even so, there does seem to be a legitimate problem.
Note that the “480M” at the end of a line implies USB2. A “5000M” implies USB3. Any USB3 HUB on a USB2 port should revert to USB2; any USB3 HUB on a USB3 root_hub should remain USB3. For reference, I am using R28.2.
This is no device at all on USB for my TX2:
# lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/3p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 480M
This is micro-USB with a USB3 HUB for my TX2 (because micro-USB is only USB2 the USB3 HUB must report as being USB2):
# lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/3p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 480M
|__ Port 1: Dev 16, If 0, Class=Hub, Driver=hub/4p, 480M
Here’s the tree when I move the USB3 HUB to the full-sized type-A connector, and a mystery begins since I have only one HUB connected and it isn’t on the micro-USB port:
# lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/3p, 5000M
|__ Port 1: Dev 4, If 0, Class=Hub, Driver=hub/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 480M
|__ Port 2: Dev 17, If 0, Class=Hub, Driver=hub/4p, 480M
Notice that USB3 properly migrates to the USB3 root_hub. What seems odd is that the micro-USB port shows a HUB! This might actually be valid operation if some sort of tricky switching is involved in the micro-USB port’s “On the Go” (“OTG”) design since this port can act as either a type-A host or a type-B device. I’ll call this a “ghost HUB”. Can someone at NVIDIA comment on whether this ghost HUB is valid and a result of being an OTG port and not a dedicated type-A port? If this anomaly is “normal” it would be good to document it. If this is not normal, then consider it a reported strangeness. Test case being HUB to micro-B as only USB connection, then switch it to full-sized USB with power still running (hot plug, not reboot cold plug) while monitoring “lsusb -t”.
Now in your case I believe your USB3 port is not functioning, at least not with that particular HUB. I think that the HUB you see on micro-USB as the USB3 HUB goes to the full-sized port is this “ghost HUB”. If that is the case, then it is unrelated to the USB3 port problem. This would be purely the result of the full-sized port not working with that particular HUB (can you verify anything else works on the full-sized port, e.g., a mouse or keyboard without a HUB?). By not having anything connected to this HUB there should be no issue with power causing it to drop out. But it is necessary to first verify something about your USB3 HUB before making that assumption…
Q: Is it correct (from previous posts) that this USB3 HUB is powered? Many powered HUBs revert to being powered from the host (instead of power cable…a.k.a., “unpowered”) if the power is disconnected, but this is not true of all powered HUBs (some HUBs simply disappear). Can you verify your power cable to the HUB puts out 5V?
Complication: In some cases a HUB may have some glitch related to sleep mode and could in theory (admittedly, this is rather unlikely) fail on one host depending on sleep mode, and yet work on another host when going in/out of sleep mode. This would still be an error, but the error would perhaps be software instead of hardware, so this is why I mention this. For all tests make sure the host has not gone into “sleep mode”. You can guarantee USB never sleeps via an edit to “/boot/extlinux/extlinux.conf”, and you should do this while testing. The “APPEND” key/value pair can have this added to disable autosuspend (reboot after this edit):
usbcore.autosuspend=-1
Example:
LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 <u><b>usbcore.autosuspend=-1</b></u>
As part of a way to see if the HUB is recognized at all, please monitor “dmesg --follow”, and then unplug and plug the USB3 HUB into the full-sized USB port. See if anything shows up. If you didn’t add the “autosuspend=-1”, then make sure to do this right after boot to be sure there is no sleep or low power mode going on. If something shows up via “dmesg --follow” during the event, then you know the hardware actually sees the HUB even though “lsusb -t” doesn’t report it. It then becomes a software issue should dmesg show up and not indicate a signal error. If nothing shows up, or if a signal error is mentioned, then you know it is a hardware issue.
Finally, one last test (this should perhaps be the first test). See if all show as “ok” from:
sha1sum -c /etc/nv_tegra_release