AGX Thor / JetPack 7.2 (R39.2.0): DisplayPort outputs dead - framebuffer@0,0 carveout is empty, reproduces on a clean official install

[deede]

On a Jetson AGX Thor Developer Kit running JetPack 7.2 / L4T R39.2.0, none of the
physical DisplayPort ports produce any output. The HDMI port works normally.

The DP ports belong to card2 (nv_platform, the SoC display engine behind DCE). The
working HDMI output comes from card1 (nvidia, the PCIe GPU). card2 connectors
stay disconnected with zero modes, regardless of what is plugged in.

The root cause appears to be BEFORE DCE: the framebuffer@0,0 reserved-memory node that
display@8808c00000 points at has status = disabled and reg = 0, so the display driver
cannot reserve its carveout, never gets a CRTC, and every subsequent DCE display RM
control call times out.

This looks related to topic 375726:

Thor DP 2/3 , cannot display,load driver error

jetson 39.2 7.2 DP 2/3 error dmesg.txt (192.6 KB) Standard DP mode (DP2 & DP3), but only 2 LAN ports (LAN0 and LAN1) are used.After the nvidia-modeset driver is loaded, the DP port is plugged in and the display works normally.If the DP port is connected and the device is powered on, the screen goes black when the nvidia-modeset driver loads, repeatedly printing the following log. [ 18.737782] [TS:40413586723] nv_platform 8808c00000.display: Adding to iommu group 90 [ 18.737870] [TS:40…

but the workaround accepted there (SOC Display Hand-Off Mode = Never, plus a cold boot)
does not help here, and our symptom is worse. In that thread the display works if the
cable is connected after nvidia-modeset loads. For us the DP ports never work, hot-plug
included.

IMPORTANT: this reproduces on a clean, official JetPack 7.2 installation. It is not
specific to our image. We reproduced it on three independent software stacks on the
same board:

Software stack                                    DP output
------------------------------------------------  ---------
Our Yocto build (OE4T meta-tegra)                 fails
Official OE4T demo image R39.2.0                  fails
  (demo-image-full-jetson-agx-thor-devkit)
Official JetPack 7.2 install                      fails
  (jetsoninstaller-r39.2.0-2026-06-01-23-53-13-arm64.iso)

The last one matters most: it is NVIDIA own installer, with NVIDIA own prebuilt UEFI
(bootloader/uefi_bins/uefi_t26x_general.bin) and root filesystem, with none of our
software involved. It produces the identical cmd:0x731341 timeout flood:

[  767.007875] NVRM: GPU1 rpcRmApiControl_dce: NVRM_RPC_DCE: Failed RM ctrl call cmd:0x731341 result 0x65: Call timed out [NV_ERR_TIMEOUT]
... repeating

In every case HDMI (from card1, the PCIe GPU) works and every DisplayPort output fails.

SETUP

Everything quoted below is from the clean official JetPack 7.2 installation, unless
noted otherwise.

Board      : Jetson AGX Thor Developer Kit (p4071-0000 + p3834-0008)
Installed  : jetsoninstaller-r39.2.0-2026-06-01-23-53-13-arm64.iso
Release    : # R39 (release), REVISION: 2.0, GCID: 45755727, EABI: aarch64,
             DATE: Mon Jun  1 09:28:48 PM UTC 2026   (KERNEL_VARIANT: oot)
OS         : Ubuntu 24.04.4 LTS (Noble Numbat)
Kernel     : 6.8.12-1021-tegra
L4T pkg    : nvidia-l4t-core 39.2.0-20260601141651
Bootloader : 39.2.0 (slot A)

SYMPTOM

$ for d in /sys/class/drm/card?; do echo $d $(basename $(readlink -f $d/device/driver)); done
/sys/class/drm/card0 drm
/sys/class/drm/card1 nvidia          # PCIe GPU 0000:01:00.0, HDMI works, 1920x1080@60
/sys/class/drm/card2 nv_platform     # SoC display via DCE, DP ports dead

$ grep . /sys/class/drm/card2-*/status
/sys/class/drm/card2-DP-1/status:disconnected
/sys/class/drm/card2-DP-2/status:disconnected
/sys/class/drm/card2-DP-3/status:disconnected
/sys/class/drm/card2-HDMI-A-1/status:disconnected

Connectors never transition to connected.

Tested with a DP-to-HDMI hub and with a direct DP-to-HDMI adapter. Both fail. The
physical HDMI port on the same monitor and cable works, so the display itself is fine.

WHAT THE LOG SHOWS - THE ORDERING MATTERS

[   10.073984] dce: dce_start_boot_flow:207  DCE_BOOT_DONE
[   13.746788] nv_platform 8808c00000.display: Cannot reserve IOVA region of 0 size
[   13.746923] nv_platform 8808c00000.display: Cannot reserve IOVA region of 0 size
[   14.557372] nvidia 0000:01:00.0: [drm] Cannot find any crtc or sizes
[   15.427921] nv_platform 8808c00000.display: [drm] Cannot find any crtc or sizes
[     ...    ] NVRM: GPU1 rpcRmApiControl_dce: NVRM_RPC_DCE: Failed RM ctrl call cmd:0x731341 result 0x65: Call timed out [NV_ERR_TIMEOUT]
... 167 occurrences, and they keep coming long after boot (e.g. t=767 s when a
cable is touched).

There is not a single hpd, dpaux, edid or sor message anywhere in the log. This command
returns 0:

dmesg | grep -icE hpd\|dpaux\|edid\|sor[0-9]

The link is never even attempted.

Two things to note.

1. DCE itself comes up correctly. DCE_BOOT_DONE is reached, firmware and KMD versions
   match (dcefw:[0x4] dcekmd:[0x4]), and the RM (type 1) and RM_NOTIFY (type 3) IPC
   channels are established. The only channel that fails at init is type 2:

   dce: dce_ipc_channel_init_unlocked:248  Invalid Channel State [0x0] for ch_type [2]
   

   Per dce-ipc.h type 2 is HDCP, and it is logged at dce_os_info level, so we read this
   as harmless and unrelated.

2. The IOVA failure precedes the RPC timeouts by about 1.5 s. The cmd:0x731341 timeouts
   look like a consequence of the display engine never having a valid framebuffer
   region, not an independent DCE fault.

[WayneWWW]

For devkit case, could you move to jp7.2.1 first?

Also, not sure why there is “all DP outputs” comment here because Thor devkit only has one DP output enabled by default.

[deede]

@WayneWWW

e, could you move to jp7.2.1 first?

Also, not sure why there is “all DP outputs” comment here because Thor devkit only has one DP output e

Thanks for pointing that out! The Thor devkit only has one DP output, so I will correct the reference.
I will find jp 7.2.1 and try it.

[deede]

I tried 7.2.1 (ISO installer) and the result is the same.

[WayneWWW]

Please use sdkmanager to do full flash instead of using ISO image.

And clarify what test you are doing there …

I don’t need you to do any analysis. Just share what thing you are testing.

For example, I am not sure why you need me to tell that there is only one DP port…

[deede]

My Thor devkit has one HDMI port and one DP port. The HDMI port outputs to the monitor. The DP port does not. I want check DP port output.(I’m using passive DP-to-HDMI cable expected to work on the devkit DP port)

And our product image is a Yocto build (OE4T meta-tegra), so SDK Manager is not part of our workflow.

[WayneWWW]

It is not a moment to stick to your workflow.

You need to confirm a baseline first. If the baseline is even failing, it could consider hardware problem.

The baseline for your usecase is NV devkit with sdkmanager and test a native DP monitor.
If even this baseline is failing, it might be hardware problem.

If this baseline is working, then change your variable (e.g. adapter/ Yocto) one by one to see which one goes wrong.

[deede]

@WayneWWW

change your variable (e.g. adapter/ Yocto) one by one to see which one goes wrong.

Since both the Yocto layer and the ISO were officially distributed by NVIDIA, I considered them to be the baseline. However, if you feel they are still not officially supported as you mentioned, I will proceed with using SDK Manager.

[WayneWWW]

The image from sdkmanager is still the most stable BSP than the other two. You could try that first.

Also, don’t forget that another key item that might bring error is that adapter… you should try native DP monitor first.