Hello NVIDIA Developer Community,
I’m experiencing persistent USB disconnections with an Intel RealSense D435 depth camera connected to my Jetson Orin NX during long-term streaming (depth and RGB). In all cases, there’s an additional non-RealSense UVC device (e.g., a MACROSILICON USB Video capture device) connected to the same USB hub, which sometimes gets affected as well. The issues occur after 10-15 hours of runtime, involving tegra-xusb errors like -32 (EPIPE), -71 (EPROTO), -75 (EOVERFLOW?), and -110 (ETIMEDOUT), often with EMI suspicions and failed enumerations. In the third scenario, it seems like the entire USB hub gets reset, impacting both devices.
I’m wondering if this points to a tegra-xusb controller limitation on Orin NX, such as power management issues, EMI sensitivity, or bugs in Jetpack 5.1.3 when handling multiple high-bandwidth UVC devices. Has anyone seen similar behavior, and would upgrading to Jetpack 6.0 or applying kernel patches resolve it?
Setup Details (Common to All Scenarios):
-
Host: Jetson Orin NX
-
Jetpack Version: 5.1.3 (L4T 35.3.1 or equivalent)
-
Kernel: Standard tegra-xusb driver
-
Camera: Intel RealSense D435 (Serial: 212223020187)
-
Firmware: 5.12.7.150
-
Additional Device: Non-RealSense UVC device (e.g., MACROSILICON USB Video, idVendor=534d, idProduct=0021)
-
SDK: librealsense (latest installed via apt, with DKMS for Jetson)
-
Connection: Both devices on direct USB 3.0 ports on Jetson (or shared hub), using short certified USB 3.0 cables
-
Streaming: Continuous depth and color streams at 30 FPS, 640x480 resolution on D435; the other UVC device is also active
-
Temperatures: ASIC ~55°C, projector <45°C (normal range)
Scenario 1: USB Protocol/Power Errors with Fallback to USB 2.0, No EMI (~15 Hours Runtime):
Note: This scenario occurred when using the original USB cable provided with the D435, which may explain the absence of EMI errors. Disconnections start with UVC query failures (-32), escalate to protocol errors (-71) in video handlers, USB power state failures (U1/U2 disable), and disconnects. The D435 reconnects as SuperSpeed Gen 1 but degrades to high-speed USB 2.0 with probe failures. The “Failed to query (GET_CUR) UVC control 1 on unit 3: -32” error often relates to IR sensor activation. The additional UVC device was unaffected here.
**Key Log Excerpts for Scenario 1 (dmesg, timestamps adjusted):
**
[Aug 20 19:24:26] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
…
[Aug 21 08:04:53] uvcvideo: Non-zero status (-71) in video completion handler. (repeated)
[Aug 21 08:04:53] usb 2-2.4: Disable of device-initiated U1 failed.
[Aug 21 08:04:53] usb 2-2.4: Disable of device-initiated U2 failed.
[Aug 21 08:04:54] usb 2-2.4: USB disconnect, device number 8
…
[Aug 21 08:04:55] usb 2-2.4: new SuperSpeed Gen 1 USB device number 9 using tegra-xusb
[Aug 21 08:04:55] uvcvideo: Failed to set UVC probe control : -32 (exp. 48). (repeated)
…
[Aug 21 08:05:37] usb 2-2.4: USB disconnect, device number 9
[Aug 21 08:05:37] usb 1-2.4: new high-speed USB device number 12 using tegra-xusb
Scenario 2: Protocol Errors Leading to EMI Suspicion and Enumeration Failures (~10 Hours Runtime):
Similar start with -32 and -71 errors, then USB disconnect, fallback to high-speed mode, and explicit EMI mention (“disabled by hub (EMI?)”). Followed by device descriptor read failures (-110 timeout, -71 protocol), power cycle attempts, and inability to enumerate the D435. The additional UVC device was unaffected.
**Key Log Excerpts for Scenario 2 (dmesg, timestamps adjusted):
**
[Aug 18 19:31:27] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
…
[Aug 19 05:02:55] uvcvideo: Non-zero status (-71) in video completion handler.
[Aug 19 05:02:55] usb 2-2.4: Disable of device-initiated U1 failed.
[Aug 19 05:02:55] usb 2-2.4: Disable of device-initiated U2 failed.
[Aug 19 05:02:56] usb 1-2.4: new high-speed USB device number 18 using tegra-xusb
…
[Aug 19 05:02:57] uvcvideo: Failed to set UVC probe control : -32 (exp. 48).
[Aug 19 05:02:57] usb 2-2.4: USB disconnect, device number 8
…
[Aug 19 05:03:11] uvcvideo: Non-zero status (-75) in video completion handler.
[Aug 19 05:10:06] usb 1-2-port4: disabled by hub (EMI?), re-enabling…
[Aug 19 05:10:06] usb 1-2.4: USB disconnect, device number 18
[Aug 19 05:10:07] usb 1-2.4: new high-speed USB device number 19 using tegra-xusb
[Aug 19 05:10:12] usb 1-2.4: device descriptor read/64, error -110
[Aug 19 05:10:22] usb 1-2.4: device descriptor read/64, error -71
…
[Aug 19 05:10:23] usb 1-2-port4: attempt power cycle
…
[Aug 19 05:10:24] usb 1-2.4: Device not responding to setup address. (repeated)
[Aug 19 05:10:24] usb 1-2.4: device not accepting address 22, error -71
[Aug 19 05:10:24] usb 1-2-port4: unable to enumerate USB device
Scenario 3: Repeated Overflow/Protocol Errors, EMI, Full Hub Reset Affecting Both Devices (~1-2 Hours Runtime, but in Context of Long Runs):
Begins with -32 queries, -71 protocol errors, then numerous repeated -75 (overflow?) in video handlers, escalating to -71 sets, EMI suspicion, disconnects, descriptor reads (-110, -71), power cycles, and enumeration failures for the D435. Notably, the additional UVC device (MACROSILICON) also gets reset multiple times, with descriptor errors and eventual re-enumeration after a power cycle—suggesting a broader USB hub/controller reset.
**Key Log Excerpts for Scenario 3 (dmesg, timestamps adjusted):
**
[Aug 17 12:46:22] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
…
[Aug 17 13:53:34] uvcvideo: Non-zero status (-71) in video completion handler. (repeated)
[Aug 17 13:53:34] usb 2-2.4: Disable of device-initiated U1 failed.
[Aug 17 13:53:34] usb 2-2.4: Disable of device-initiated U2 failed.
[Aug 17 13:53:34] usb 2-2.4: USB disconnect, device number 7
[Aug 17 13:53:35] usb 1-2.4: new high-speed USB device number 10 using tegra-xusb
…
[Aug 17 13:53:35] uvcvideo: Failed to set UVC probe control : -32 (exp. 48).
…
[Aug 17 13:53:45] uvcvideo: Non-zero status (-75) in video completion handler. (repeated extensively)
[Aug 17 13:53:45] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024). (repeated)
…
[Aug 17 13:56:25] uvcvideo: Failed to query (SET_CUR) UVC control 1 on unit 3: -71 (exp. 1024).
[Aug 17 13:56:25] usb 1-2-port4: disabled by hub (EMI?), re-enabling…
[Aug 17 13:56:25] usb 1-2.4: USB disconnect, device number 10
[Aug 17 13:56:25] usb 1-2.4: new high-speed USB device number 11 using tegra-xusb
[Aug 17 13:56:30] usb 1-2.4: device descriptor read/64, error -110
…
[Aug 17 13:56:41] usb 1-2-port4: attempt power cycle
…
[Aug 17 13:56:42] usb 1-2.4: Device not responding to setup address. (repeated)
[Aug 17 13:56:43] usb 1-2-port4: unable to enumerate USB device
…
[Aug 18 06:50:34] usb 1-2.2: reset high-speed USB device number 7 using tegra-xusb (repeated resets for additional UVC device)
[Aug 18 06:50:34] usb 1-2.2: device descriptor read/64, error -71 (repeated)
…
[Aug 18 06:50:36] usb 1-2.2: USB disconnect, device number 7
…
[Aug 18 06:50:38] usb 1-2.2: new high-speed USB device number 17 using tegra-xusb
[Aug 18 06:50:38] usb 1-2.2: New USB device found, idVendor=534d, idProduct=0021… (re-enumerated after cycle)
I’ve tried updating librealsense DKMS for Jetson, but problems persist across scenarios, especially with multiple UVC devices. Is this a known tegra-xusb issue on Orin NX, like insufficient power for bandwidth-heavy peripherals, EMI interference, or Jetpack 5.1.3 bugs causing hub resets? Could it be mitigated by external powered hubs, USB shielding, disabling autosuspend, or upgrading to Jetpack 6.0? Any experiences with similar USB instability on Orin NX would be helpful.
Thanks for any insights or workarounds!