Xusb not supporting USB bulk transfer (e.g. needed for kinectv2 and another high performance cams)

Hello, I have Jetson Nano 2GB and have connected a Kinect V2. And have modify the boot script:
sudo nano /boot/extlinux/extlinux.conf
APPEND ${cbootargs} usbcore.autosuspend=-1 usbcore.usbfs_memory_mb=256 usb_port_owner_info=2 root=/dev/mmcblk0p1

The kinect V2 running correct, but after short time all USB connection are dead. Every thing else works.
I have debug it an get following data:
dmesg -H -w
error: tegra-xusb70090000.xusb: hcd_reinit is disabled or in progress usbfs_usb_submit_urb returned -22`

I guess, the problem is to found inside the xusb firmware from jetson nano at USB bulk transfers handling.
Are the plans to overwork or fix xusb for Jetson nano 2GB and Jetson nano 4GB?

Please try on Nano 4GB. USB bulk mode should work fine. Probably the issue is due to insufficient memory.

I have tested it already on Jetson Nano 2GB and 4GB. It is the xusb that make here a problem.
On Jetson Nano 4GB more than on 2GB, because on Jetson Nano 2GB it will run, on jetson nano 4GB the crash will take place direct after the first start.
Use a kinectv2 or another high performance cam to investigate this.
You will found inside the forum a several entrys releated to this xusb issue, because the visible error is at the end, that the USB ports does not longer work. If that error happens, then it is not possible to reset the USB ports manualy via command line (unbind/bind).
Mean USB is absolut crahed. The reason is:
error: tegra-xusb70090000.xusb: hcd_reinit is disabled or in progress usbfs_usb_submit_urb returned -22`

I couldn’t tell you what the specific issue is. You do definitely have a USB problem, but if bulk transfer is involved, then it is coincidental (e.g., maybe too much buffer required or timing of using the buffer is delayed until not enough buffer is available). The Jetsons definitely work with bulk transfer mode (isochronous in device mode is another story).

Please share steps from device enumeration to reproducing the issue. And full dmesg for reference.
Please also share your release version( $ head -1 /etc/nv_tegra_release ).

There are 4-port on Jetson Nano developer kit and you should only connect one USB3 device. Please confirm this also.

Hello DaneLLL,
thx for your support.
head -1 /etc/nv_tegra_release

Jetson Nano 2GB:

# R32 (release), REVISION: 6.1, GCID: 27863751, BOARD: t210ref, EABI: aarch64, DATE: Mon Jul 26 19:20:30 UTC 2021

Jetson Nano 4GB:

# R32 (release), REVISION: 6.1, GCID: 27863751, BOARD: t210ref, EABI: aarch64, DATE: Mon Jul 26 19:20:30 UTC 2021

I have connected only the kinnect to usb 3.0 port.

Here the log file from Jetson Nano 4GB:kv2NoUSB.log (65.7 KB)

Here the log file from Jetson Nano 2GB: kv2NoUSB_JN2GB.log (82.1 KB)

Thanks for the log. We don’t have the device and would need your help to provide more information. So it actually has three USB devices:

[  +0,000004] usb 1-2.3: Product: G11 Keyboard
[  +0,000004] usb 1-2.3.3: Product: Cherry USB Optical Mouse
[  +0,000004] usb 2-1.2: Product: Xbox NUI Sensor

Please also share lsusb-v for reference.

And please try to connect to USB hub with external power supply and the connect to Jetson Nano. Would like to know it it works fine or no with external power supply to the USB devices.

No problem:
JetsonNano2GB: lsusbMinusV_JN2GB.log (22.1 KB)

JetsonNano4GB: lsusbMinusV_JN4GB.log (24.3 KB)

The Mouse is connected to the Keyboard. The Keayboard is a USB-HUB :-)
During the test I have unplugged the keyboard and have start all via VNC remote control(ethernet). Add the end the kinectv2 was connected with USB-Port , only.
For JN2GB I use a powersupply with 3A, for JN4GB I use a power supply with 6A.
I have try to use an external USB hub. The result is the same like before.
I have seen that the memory consumption during running the kinnectv2 is around 1.06 GB.

Did you try with an external HUB which is powered separately from the Jetson? Or did you try with the HUB being powered by the USB cable itself? It would be important to try with a HUB which has separate power which does not rely on the Jetson providing the power.

Hi, I use an USB-HUB with external power supply(Model DUB-H7 - D-Link - 5V - 3A).

Please share steps in detail for reference. Currently we don’t have the device. Will check if we can get one and try to reproduce the failure step-by-step.

I have deliver already the log files. How can I deliver more step-by-step ?
By the way, I have found out one root issue.
I have buy several USB3.0 A to B cable with different length (0.6m, 1.0m).
And I found out that I have less trouble, if I use a shorter cable.
I have setup an Rasspberry Pi 4 and could let run a kinnect v2 stabel for several hours. The Jetson Nano after more or less between 10 min or 1 hour stop with tegra xusb error. If I let run the kinnect 2 with option --norgb (means less data transfer), the error is coming later (I guees between 30 min and 2 hours). And If I use the 0.6m cable and the option --norgb, than I have for 2 hours no error detected. Perhaps, you can build a test setup on your side and simulate transfer error rates and test how stable the xusb driver is again transfer errors. (mean, you can use a very long cable to force the error , e.g. 5.0m USB3.0 cable)

We would need more information about the device. Does it work like a USB camera? If yes, we will try to run a gstreamer command for reproducing the failure.

Hi, the device I use is a Kinect Xbox one (Kinect - Wikipedia). I found under following URL(Xbox One Kinect Review) a block diagram. grafik.
If you need a dataset for your test: (https://www.cvl.isy.liu.se/en/research/datasets/kinect2-dataset/) The Linux driver and more background infos are located here: GitHub - OpenKinect/libfreenect2: Open source drivers for the Kinect for Windows v2 device .Hope that will help you.

I have not looked up details, but since this is a custom driver over USB you might want to also include the verbose “lsusb”. In USB the manufacturer ID for Microsoft is hexadecimal “045e”, and it looks like the device has various subcomponents (each with its own ID). Thus (just going by the USB ID database) this would list all USB devices which are Microsoft:
lsusb -d "045e:"

Any device which shows up under the Microsoft ID would probably have one of these device IDs:

	02bb  Kinect Audio
	02be  Kinect for Windows NUI Audio
	02bf  Kinect for Windows NUI Camera
	02c2  Kinect for Windows NUI Motor

Are you using only the camera part of this (or is it just the camera part which has the issue)? If so, then the query could be limited to the camera via the full ID:
`lsusb -d 045e:02bf’

The fully verbose version of this, along with creating a log file of the verbose lsusb, would be:
sudo lsusb -d 045e:02bf -vvv 2>&1 | tee log_kinect_camera.txt'
(then attach a copy of the log_kinect_camera.txt to the thread)

The reason I suggest adding this information is that it might make it easier looking through both logs and kernel code to know it is that exact device.