Onboard USB3 flaky, but with USB3 hub works fine

Autonomous Machines Jetson & Embedded Systems Jetson TX1
#1

I’ve noticed odd performance on our TX1 system with a USB3 camera (Point Grey).

When the camera is plugged into the onboard USB3 port, I can transfer data from the camera with a barebones app that just pulls images from the data stream, but if I use their GUI with settings control etc. the GUI consistently hangs on startup.

When I plug the same camera into a USB3 hub, both data transfers and the GUI work just fine.

With a PCI card with USB3 everything works fine as well.

I’ve noticed other forum posts about this, but none that exactly address the onboard USB3 vs USB3 hub issue.

I can insert a hub into my system, it just makes things a bit kludgy. Is the hub doing some sort of buffering to smooth over whatever the onboard USB3 is having issues with?

#2

Are you able to use serial console while it hangs? If not, does ping or ssh work? There may be dmesg logs or X11 logs.

#3

I don’t see any differences on the logs. Ping/ssh both work as well as terminals.

When I run lsusb -t I do get slightly different output

When I am through the USB3 hub:

/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
|__ Port 2: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 4: Dev 12, If 0, Class=Miscellaneous Device, Driver=, 5000M
|__ Port 4: Dev 12, If 1, Class=Miscellaneous Device, Driver=, 5000M
|__ Port 4: Dev 12, If 2, Class=Miscellaneous Device, Driver=, 5000M

When I am direct into the camera:

/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
|__ Port 2: Dev 13, If 0, Class=Miscellaneous Device, Driver=usbfs, 5000M
|__ Port 2: Dev 13, If 1, Class=Miscellaneous Device, Driver=, 5000M
|__ Port 2: Dev 13, If 2, Class=Miscellaneous Device, Driver=usbfs, 5000M

Is the usbfs driver an issue or is this just nothing?

Any other debugging steps to try?

#4

I don’t think usbfs is involved. You would see “/proc/bus/usbfs”. There is instead “/sys/bus/usb” (I’m not sure, I think this is “usbdevfs”) access which is newer. So far as I know drivers themselves do not depend on this.

What seems odd is that if your camera is plugged into the USB3 hub or PCIe card you should see it as a child in the “lsusb -t” tree. I do not see the actual camera.

Having a hub could improve signal quality or timing even if the hub is not externally powered. An externally powered hub could definitely fix power delivery issues. A PCIe USB3 card would have its own design for circuit board traces and possibly be more or less tolerant to signal quality versus the onboard USB3 (there is some similarity between effects of using a powered USB3 hub versus PCIe card).

If you are ambitious, you might install packages strace and ltrace (they give C-like debugging information). strace gives debug information for system calls…basically the services the application requires from the kernel. ltrace provides debug information for calls to libraries…libraries being in user space. These both put out an enormous amount of data about all kinds of things you won’t be interested in, e.g., lots of failure messages for detecting certain character sets in every language…but if you only installed en_US, those other character sets are expected to fail.

If the application crashes under strace or ltrace, you’re in luck, because only around the last 100 lines or so of their output will have crash details.If the application locks up, very likely it is spinning its wheels on something and will repeatedly output the same messages over and over as fast as the computer can do it (and that’s fast). You basically would have to manually kill the app very quickly after it locks, and then manually delete out the repetitive non-informative calls from the end of the log until you get to something interesting. Since this may involve thousands of lines you’d need patience.

For your particular case I don’t know if sudo is used or needed, but the basic syntax is:

strace -olog_strace.txt ...the command for running your camera gui...
# or...
ltrace -olog_ltrace.txt ...the command for running your camera gui...