Hi,
We’re experiencing two USB3 issues on Jetson Orin platforms that we believe originate in the xusb controller firmware. We’ve verified these with a Total Phase Beagle 5000 V2 protocol analyzer.
Environment:
- Jetson Orin NX 16GB (custom carrier, R36.4.4, kernel 5.15.148) and Jetson Orin Nano Super devkit (stock R36.5.0, kernel 5.15.185-tegra)
- Two USB3 cameras from different vendors, both using the Infineon CYUSB3065 CSI-to-USB3 bridge in bulk mode, streaming 3840x2160 MJPEG at 30fps
- Both cameras work flawlessly on an Ubuntu laptop
Issue 1: ITP frame count errors
On the Beagle 5000, we see a consistent ITP frame count error rate (~425 errors/second) when either camera is connected to the Jetson. We see zero ITP errors when the same cameras are connected to a standard Ubuntu laptop with the same cable and analyzer inline. We also tried with a third camera with a different chip, using isochronous transfer, and could not see the errors on that camera.
Issue 2: ~1.6s complete USB transfer stall
Periodically, all USB3 transfers stall for approximately 1.5 seconds and then silently resume. Under normal load this happens roughly once per hour; under DDR memory pressure (stress -d 3 on a tmpfs mount) it happens multiple times per minute. Both the Orin NX and the Orin Nano devkit reproduce this. (This issue was observed with the primary camera. We have just started testing with the second camera and have mainly focused on the ITP frame count error until now.)
We’ve captured this stall at every level:
- Wire level (Beagle 5000): The host sends an ACK with NumP=0 (stop sending data) and then issues zero IN transactions for 1.531 seconds. The camera was never asked for data.
- Kernel level (ftrace): Zero xHCI events for 1.507–1.536s. The event ring TRB addresses are perfectly sequential across the gap, no events lost, the firmware just stopped writing.
- Doorbell trace: During the stalls, the host kernel rang the endpoint doorbell constantly. The controller ignored all of them.
- UVC trace: SoF advances only +1 during the 1.5s stall (should be ~12,000 at 8kHz), and STC is frozen at 384,000. The Beagle capture confirms 816 ITPs were sent during the stall, but the camera did not incorporate them — likely because no IN transactions were being scheduled. The camera’s own PTS clock advanced by 1,599 (~1.6s), confirming it was alive and waiting.
The ~1.5s duration is highly deterministic, suggesting a firmware-internal watchdog or timeout triggers the recovery. Recovery is silent — no errors, no re-enumeration, no link retraining.
What we’ve ruled out: USB LPM, autosuspend, CPU starvation, EMC frequency (tested at 665/2133/3199 MHz - no effect), link disconnects, camera-side fault.
Trigger: DDR memory contention. stress -d 3 on tmpfs (pure RAM) or stress -m 4 --vm-bytes 512M triggers it reliably. stress -d 3 on NVMe does not. Max EMC frequency does not help - it’s latency-sensitive contention, not bandwidth starvation. But also without stressing the system, it happens once in a while.
Questions:
1. Are these known issues with the Tegra234 xusb firmware?
2. Is there an updated xusb firmware available for testing?
3. Will Jetpack 7.2 include the a different xusb firmware?
We can provide Beagle 5000 captures, ftrace logs, and or other kernel traces. Happy to run any additional tests.
Thank you.
