Jetson Orin NX unstable with ASM2142 PCIe‑USB3 card and multiple UVC cameras (AER Fatal / HC died / error -110)

[2233852675]

I am building a multi‑camera USB system on a Jetson Orin NX. My goal is to run one 4K camera and three 2K cameras stably at the same time (preferably using compressed formats such as MJPEG/H.264) for real‑time preview and recording.
My current environment is: Jetson Orin NX.
The software version is JetPack 6.2.1 (nvidia-jetpack 6.2.1+b38), and the underlying L4T version is 36.4.7 (nvidia-l4t-core 36.4.7-20250918154033).
I am using a PCIe‑USB3 expansion card based on the ASMedia ASM2142 controller, plus several UVC cameras.

Currently I have two major issues.
First, when I connect cameras to the USB ports on the ASM2142 PCIe‑USB3 expansion card, even with only one USB2.0 camera attached (for example 2K resolution at about 23 fps), after running for some time the system randomly reports serious PCIe and xHCI controller errors.
Typical kernel logs include:
pcieport ... AER: Uncorrected (Fatal) error, PCIe Bus Error ... SDES,
and also xhci_hcd ... xHCI host controller not responding, assume dead, HC died; cleaning up,
followed by messages like xhci_hcd ... ERROR Transfer event TRB DMA ptr not part of current TD and usb x-y: device descriptor read/8, error -110/-108.
After these errors occur, all USB cameras connected to this ASM2142 card drop offline: accessing /dev/video* from user space either fails to open or opens but delivers no data.
I also notice that after such an error, even if I physically unplug the PCIe expansion card, lsusb -t still shows the controller and its ports under this card.
So far I have only been using a full system reboot to restore a “clean” device state.
To mitigate the problem, I have tried lowering the resolution and frame rate of the cameras, replacing the PCIe‑USB3 expansion card, USB cables and power supply, but these AER Fatal and xHCI “HC died” issues still keep happening.

Second, if I do not use the ASM2142‑based expansion card at all and only use the on‑board USB3 controller of the Orin NX (the USB‑C and USB‑A ports are actually on the same xHCI controller), opening any single USB3.0 camera works fine.
However, when I try to open multiple USB3 cameras simultaneously (for example one 4K + any one 2K camera, or more), usually only one camera can be started successfully.
The other cameras fail to open at the application level or show no video data.
This behavior looks more like a limitation of the actual available bus bandwidth or a combination of UVC video formats (uncompressed YUYV vs compressed MJPEG/H.264), but I haven’t found clear official documentation about the bandwidth limits or recommended configuration for multi‑high‑resolution UVC cameras on Orin NX.

Based on the above, I would like to ask NVIDIA engineers and the community:

1. When using Jetson Orin NX together with PCIe‑USB3 controllers based on ASMedia ASM2142, are the above errors (AER Fatal, xHCI “HC died”, error -110/-108, etc.) known compatibility or driver issues?
   Are there any PCIe‑USB controllers (for example Renesas‑based cards) that are officially recommended or validated to be more stable on Orin NX, and are there any additional kernel parameters, device‑tree settings, or patches that could help improve this situation?
2. If I only rely on the SoC’s on‑board USB3 controller, what is the recommended configuration to run one 4K + three 2K UVC cameras simultaneously, in terms of resolution, frame rate, encoding format (trade‑off between YUYV and MJPEG/H.264), and port/controller topology?
   What is the approximate practical usable bandwidth of the Jetson Orin NX on‑board xHCI controller when multiple high‑resolution cameras are running at the same time?
   If needed, I can provide full dmesg, lspci -vvv, and lsusb -t outputs for further analysis.

[linuxdev]

Beware you’re using the Orin NX, but this is listed in the older Nano (a TX1) forum. This is the correct forum:
https://forums.developer.nvidia.com/c/robotics-edge-computing/jetson-embedded-systems/jetson-orin-nx/487
(someone from NVIDIA might move the post to there)

I cannot answer, but will get something started. You can use the “lspci -vvv” along with the “-s <slot>” option to limit the query to one specific device slot. Run “lspci”, find the slot, and then make a log of any relevant device(s):
sudo lspci -s <slot> -vvv 2>&1 | tee log_pci.txt
(you might need a different log name if you are showing two or more devices)

You can also do the same for the “slightly” verbose tree view:
lspci -v -t 2>&1 | tee log_tree.txt

Try to do this before any error (you might not find that possible), and after the error. Attach those to the forum.

Also, watch “dmesg --follow” as you work. A copy of the full boot log would help, prior to experimenting or errors if possible:
dmesg 2>&1 | tee log_initial_dmesg.txt
(remember you can copy and paste that, or you can simply run a serial console with logging enabled the whole time)

When starting a specific test, or when something specific has occurred, and when that shows up in the dmesg log, it would help to have a copy of the message for that specific event (not mixed in with other messages we can’t separate).

Very specifically, is the model of Jetson a developer’s kit? Or does it use some form of third party carrier board?

There isn’t a lot that can be said about that small excerpt of a log. Sometimes such a thing might be from misconfiguration, sometimes it might be from power issues, sometimes it is from signal quality (this is the one I usually bet on). If there isn’t more information it is nearly impossible to guess at this.

Do note that you can show the lspci verbose output for both the camera and PCIe device. An example of this being useful is if there is an error and the log indicates this for the USB device, but not for the PCIe card. Knowing which errors first, even if it is just by milliseconds, might be useful.

[2233852675]

log_initial_dmesg.txt (62.0 KB)

log_tree.txt (450 Bytes)

log_pci.txt (85 Bytes)
Hi, I would like to provide an update with the additional tests and logs you requested.

Following your suggestion to simplify the setup, I ran a test with only one UVC camera connected to a single USB3 port on the ASM2142 PCIe‑USB3 card. The camera was configured at 2560×1440 MJPEG, and I used the following GStreamer pipeline on the Jetson Orin NX:

gst-launch-1.0 -v
v4l2src device=/dev/video0 !
“image/jpeg,width=2560,height=1440” !
jpegparse ! nvv4l2decoder mjpeg=1 ! nvvidconv !
videorate !
“video/x-raw(memory:NVMM),width=2560,height=1440,format=I420” !
nvvidconv ! “video/x-raw(memory:NVMM),width=2560,height=1440,format=I420” !
nvv4l2h264enc bitrate=2000000 iframeinterval=5 preset-level=1 insert-sps-pps=true !
h264parse config-interval=1 ! “video/x-h264,stream-format=avc,alignment=au” !
rtspclientsink location=rtsp://127.0.0.1:8554/left_sub
protocols=tcp retry=3 timeout=5

The RTSP server is running on 127.0.0.1:8554, so the client sink can connect successfully. I also tested similar pipelines with fakesink instead of RTSP to make sure the behavior is not caused by the RTSP side.

In this single‑camera test, after the pipeline had been running for some time, the camera stream stopped working and dmesg showed repeated resets of the SuperSpeed device together with descriptor read timeouts, for example:

[ 255.583713] usb 4-1: reset SuperSpeed USB device number 2 using xhci_hcd [ 260.829911] usb 4-1: device descriptor read/8, error -110 [ 260.937506] usb 4-1: reset SuperSpeed USB device number 2 using xhci_hcd

This pattern (reset → “device descriptor read/… error -110” → reset) keeps repeating. As far as I understand, -110 is ETIMEDOUT, i.e. the xHCI controller tries to read the USB device descriptor but the device does not respond in time.

In earlier multi‑camera tests on the same ASM2142 controller (as described in my original post), I also captured xHCI internal errors such as:

xhci_hcd 0007:01:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 xhci_hcd 0007:01:00.0: HC died; cleaning up

After those messages, all cameras on this controller stopped working until I rebooted the system. So across different runs I have seen both:

1. controller‑internal TRB / “HC died” errors, and

2. repeated resets with “device descriptor read/… error -110” when trying to re‑enumerate the device.

According to your instructions, I have collected and attached the following basic logs:

1. Initial dmesg snapshot:

dmesg 2>&1 | tee log_initial_dmesg.txt

This file (log_initial_dmesg.txt) contains a full kernel log snapshot after boot and before starting the single‑camera test.

2. Detailed PCIe information for the ASM2142 device:

sudo lspci -s <ASM2142_BDF> -vvv 2>&1 | tee log_pci.txt

In my system <ASM2142_BDF> is for example 0007:01:00.0. The file log_pci.txt contains the complete PCIe configuration for the ASM2142 controller, including link status and AER counters.

3. PCIe topology tree:

lspci -v -t 2>&1 | tee log_tree.txt

The file log_tree.txt shows the PCIe hierarchy and how the ASM2142 card is connected to the Orin NX.

In addition to these three logs, for this single‑camera test I also recorded a full dmesg after the error occurred, and a live “dmesg --follow” log during the test (showing when the resets and error -110 messages start). I can provide these extra logs as well if they are useful.

Given this new single‑camera result on the ASM2142 card (resets + “device descriptor read/… error -110”), together with the earlier multi‑camera logs that show “Transfer event TRB DMA ptr not part of current TD” and “HC died; cleaning up”, could you please advise whether this looks like:

• a known compatibility or xHCI driver issue for ASM2142 on Jetson Orin NX, or

• more likely a hardware / signal integrity problem with this controller on Orin NX?

If there are any recommended workarounds (kernel parameters, xHCI quirks, patches, or a different PCIe‑USB3 controller) to reliably run one 4K + three 2K UVC cameras on Orin NX, I would really appreciate your guidance. If you need any additional specific logs or a different test pattern (for example, comparing the same camera on the SoC on‑board USB3 versus on the ASM2142 card), I am happy to run those tests and upload the results.

Thank you again for your help.

[linuxdev]

Incidentally, maybe someone from NVIDIA could move this to the Orin NX forum.

---

Starting with logs, I’m unable to see something specific other than this repeating log message:
ACK 04 d4

I do not know what that is from, but it always occurs after network devices logged something “normal”. I had hoped for evidence as to a specific source of issue to tell if it is the PCIe side or the USB side (remember that it is a USB device communicating through a PCI root HUB; probably it is the PCI side, but it isn’t proven yet; the messages you noted do prove PCI is an issue, but it provides no true detail).

The actual ASMedia card looks like it is in PCIe slot 0007:01:00.0 (it is a bit longer than I normally see, but I think that is still correct). Can you see this one specific PCIe card if you run this command?
lspci -s 0007:01:00.0

If so, then get the fully verbose output (requires sudo) in a log after some error has taken place:
sudo lspci -s 0007:01:00.0 -vvv 2>&1 | tee log_verbose.txt

That log should help narrow it.

I would also like to know about how the ASMedia device is being powered. Is it purely through the PCIe slot? Closely related to that, how is each USB device you plug into this powered? The nature of the question is much simpler if each USB device has its own power, and the easiest of all is if the PCIe card also has its own power. As soon as one device draws power from another things can change and “appear” to look like a hardware error, and yet the reason for the “bad” hardware can actually be power delivery. We don’t know, but between those answers and the fully verbose lspci log we should be able to get more information to answer that.

Incidentally, there is yet another possible twist in the story: Is this an NVIDIA Orin NX developer’s kit? Or is this from a third party with their own carrier board? This question is critical because it changes firmware, and firmware too can drastically change answers. If the firmware is incorrect, then it could be errors from software talking to the wrong device. For the case of a developer’s kit there would be an SD card slot on the back of the module itself. There would be no eMMC. If the module is commercial (and not from a developer’s kit), then it has eMMC, and any SD card slot would move to the carrier board. Third party firmware usually means flashing with software other than the default NVIDIA flash software (but not always; even if it is wrong, then usually a large part of hardware still works correctly).