Jetson Orin Nano Developer Kit Super (VFS failed, DCE errors, GPU unstable under load) - RMA request

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
1

Hardware: Jetson Orin Nano Developer Kit Super variant
Serial: 1424924359547
JetPack: R39.2.0 (fresh flash, also occurred on R36.5.0)
Kernel: 5.15.185-tegra
GPU UUID: 497e512c-89ce-5a86-ade6-f7de8233865a

Three hardware-level issues, all persisting across JetPack versions and power cycles:

  1. GPU DVFS completely non-functional

    • “devfreq 17000000.gpu: dvfs failed with (-22) error” every ~30ms
    • GPU stuck at 612 MHz in default mode
    • All 8 available frequencies (306-1020 MHz) fail to set via userspace governor
    • Only workaround: lock to performance governor at 918 MHz (bypasses DVFS entirely)

  2. Display controller errors (from boot, no display changes affect it)

    • “NVRM rpcRmApiControl_dce: Failed RM ctrl call cmd:0x731341 result 0xffff” every 5s
    • “NVRM rpcRmApiControl_dce: Failed RM ctrl call cmd:0x730282 result 0x1f” every 5s
    • Black screen after UEFI logo on connected display

  3. GPU unstable under sustained CUDA load

    • Small workloads pass (200x 2000x2000 matmuls)
    • Full-resolution training (1024x1344, batch=2) crashes after 100 iterations
    • Crash: NVML_SUCCESS == r INTERNAL ASSERT FAILED at CUDACachingAllocator.cpp:838

Temperatures well within spec (idle 48°C, load 65°C).
Official NVIDIA 15V/3A power supply, 19W draw under load.
No overclocking, no custom settings. Default nvpmodel mode 1 (25W).

NVIDIA live support (Adfar Banday) confirmed this appears to be a hardware-level fault and directed me here for forum review before RMA processing.

5

Hi,

Before proceeding with a hardware-fault or RMA assessment, we need to resolve an inconsistency in the reported software versions.

Jetson Linux R39.2.0 is included with JetPack 7.2 and uses the 6.8 kernel. The reported kernel, 5.15.185-tegra, is from the R36.x kernel family; Jetson Linux R36.5 uses kernel 5.15. Therefore, the information provided does not yet demonstrate that the failures reproduced on a complete R39.2 installation.

This mismatch may be a reporting mix-up between the R39.2 and R36.5 tests, or it may indicate that the system is still booting an older kernel or another storage device. Either way, the current information does not establish a board-level hardware fault.

Please provide the complete output of the following commands from the currently running system:

head -n 1 /etc/nv_tegra_release
uname -r
findmnt -no SOURCE,FSTYPE /
cat /proc/cmdline

Recommendation: Please collect this output immediately after a normal boot, before applying the performance-governor frequency lock. Once we confirm that the running kernel, root filesystem, and BSP all belong to the same release, we can determine whether further logs or hardware evaluation are needed.

References:

Thanks.