Orin Nano Developer Kit, R39.2.1: "DCE ucode abort" after dce-fabric SLAVE_ERR on DP replug, display dead until reboot (DP MST hub in path)

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
,
1

Hi,

On a Jetson Orin Nano Developer Kit running JetPack 7.2.1 / Jetson Linux
R39.2.1, unplugging and replugging the DP cable between the board and a DP
MST hub causes a dce-fabric SLAVE_ERR followed by a DCE ucode abort. After
that, every DCE IPC call times out and the display never recovers until the
system is rebooted.

I have reproduced this on a completely clean setup: an unmodified developer
kit, freshly flashed with the stock BSP and the NVIDIA sample root
filesystem, with no device tree changes and no application software of our
own. The full log is attached.

Environment

  • Module: Jetson Orin Nano
  • Board: Jetson Orin Nano Developer Kit (not a custom carrier board)
  • JetPack 7.2.1, Jetson Linux R39.2.1
  • Freshly flashed with the NVIDIA sample root filesystem
  • No device tree modifications, no additional software installed
  • $ cat /etc/nv_tegra_release
# R39 (release), REVISION: 2.1, GCID: 46758480, BOARD: generic,
EABI: aarch64, DATE: Fri Aug  7 05:54:22 AM UTC 2026
# KERNEL_VARIANT: oot
  • Display topology:
    Orin Nano DP output → DP cable → VMM6200 DP hub → HDMI 2.0 output
  • Monitor: 1x 1920x1080 @ 60Hz, connected to one of the hub’s two HDMI
    outputs (the other output is unused)

How to reproduce

  1. Boot with the monitor connected through the VMM6200 hub. The display
    works normally.
  2. While Linux is running, unplug the DP cable between the developer kit
    and the hub. The failure occurs regardless of which end of the cable I
    unplug - the developer kit side or the hub side.
  3. Plug it back in slowly. Speed matters: if the connector is inserted
    quickly and cleanly, the display usually recovers normally. If the
    insertion is slow - the kind of fumbling that happens when someone plugs
    a cable in by hand without looking - the failure occurs. It is not an
    exotic timing; simply taking a moment to seat the connector is enough.
    Once the insertion is slow, it reproduces 100% of the time.
  4. The error appears and the display never comes back. A full reboot is the
    only recovery I have found.

Isolation test already performed

I removed the hub and connected the monitor directly to the Orin Nano DP
port with a plain DP-to-DP cable - no adapter or converter of any kind -
and repeated the same unplug/replug 10 times. The error did NOT occur and
the display came back every time. The problem only appears when the VMM6200
hub is in the path, and specifically when the upstream DP link between the
board and the hub is broken and restored.

Log

The full log is attached. The relevant part is below.

Jan 01 09:01:26 a pipewire[2463]: mod.adapter: 0xaaaaf2f35a80: can't get format: Device or resource busy
Jan 01 09:01:26 a wireplumber[2465]: <WpNode:0xaaab0127b1b0> Object activation aborted: PipeWire proxy destroyed
Jan 01 09:01:26 a wireplumber[2465]: <WpNode:0xaaab0127b1b0> ignoring set_param on already destroyed objects
Jan 01 09:01:27 a wpa_supplicant[1676]: dbus: fill_dict_with_properties dbus_interface=fi.w1.wpa_supplicant1.Interface.Mesh dbus_property=MeshPeers getter failed
Jan 01 09:01:30 a dhcpd[2003]: DHCPREQUEST for 192.168.55.100 from 5e:8f:e2:0d:b2:b8 (System-Product-Name) via l4tbr0
Jan 01 09:01:30 a dhcpd[2003]: DHCPACK on 192.168.55.100 to 5e:8f:e2:0d:b2:b8 (System-Product-Name) via l4tbr0
Jan 01 09:01:30 a wpa_supplicant[1676]: dbus: fill_dict_with_properties dbus_interface=fi.w1.wpa_supplicant1.Interface.Mesh dbus_property=MeshPeers getter failed
Jan 01 09:01:32 a kernel: CPU:0, Error: dce-fabric@0xde00000, irq=32
Jan 01 09:01:32 a kernel: **************************************
Jan 01 09:01:32 a kernel: CPU:0, Error:dce-fabric, Errmon:2
Jan 01 09:01:32 a kernel:           Error Code                : SLAVE_ERR
Jan 01 09:01:32 a kernel:
Jan 01 09:01:32 a kernel:           Error Code                : SLAVE_ERR
Jan 01 09:01:32 a kernel:           MASTER_ID                : DCE
Jan 01 09:01:32 a kernel:           Address                : 0x13806540
Jan 01 09:01:32 a kernel:           Cache                        : 0x1 -- Bufferable
Jan 01 09:01:32 a kernel:           Protection                : 0x3 -- Privileged, Non-Secure, Data Access
Jan 01 09:01:32 a kernel:           Access_Type                : Write
Jan 01 09:01:32 a kernel:           Access_ID                : 0x0
Jan 01 09:01:32 a kernel:           Fabric_Id                : 0x0
Jan 01 09:01:32 a kernel:           Fabric                : cbb-fabric
Jan 01 09:01:32 a kernel:           Slave_Id                : 0x37
Jan 01 09:01:32 a kernel:           Burst_length                : 0x0
Jan 01 09:01:32 a kernel:           Burst_type                : 0x1
Jan 01 09:01:32 a kernel:           Beat_size                : 0x2
Jan 01 09:01:32 a kernel:           VQC                        : 0x0
Jan 01 09:01:32 a kernel:           GRPSEC                : 0x3f
Jan 01 09:01:32 a kernel:           FALCONSEC                : 0x0
Jan 01 09:01:32 a kernel:         **************************************
Jan 01 09:01:32 a kernel: dce: dce_handle_irq_status:272  DCE ucode abort occurred
Jan 01 09:01:33 a wpa_supplicant[1676]: dbus: fill_dict_with_properties dbus_interface=fi.w1.wpa_supplicant1.Interface.Mesh dbus_property=MeshPeers getter failed
Jan 01 09:01:34 a systemd[1]: serial-getty@ttyGS0.service: Deactivated successfully.
Jan 01 09:01:34 a systemd[1]: serial-getty@ttyGS0.service: Scheduled restart job, restart counter is at 1.
Jan 01 09:01:34 a systemd[1]: Started serial-getty@ttyGS0.service - Serial Getty on ttyGS0.
Jan 01 09:01:35 a systemd[1]: systemd-localed.service: Deactivated successfully.
Jan 01 09:01:36 a systemd[1]: systemd-hostnamed.service: Deactivated successfully.
Jan 01 09:01:36 a wpa_supplicant[1676]: dbus: fill_dict_with_properties dbus_interface=fi.w1.wpa_supplicant1.Interface.Mesh dbus_property=MeshPeers getter failed
Jan 01 09:01:36 a systemd-resolved[509]: Using degraded feature set UDP instead of TCP for DNS server 8.8.8.8.
Jan 01 09:01:37 a systemd[1]: fprintd.service: Deactivated successfully.
Jan 01 09:01:37 a dhcpd[2003]: DHCPREQUEST for 192.168.55.100 from 5e:8f:e2:0d:b2:b8 (System-Product-Name) via l4tbr0
Jan 01 09:01:37 a dhcpd[2003]: DHCPACK on 192.168.55.100 to 5e:8f:e2:0d:b2:b8 (System-Product-Name) via l4tbr0
Jan 01 09:01:39 a wpa_supplicant[1676]: dbus: fill_dict_with_properties dbus_interface=fi.w1.wpa_supplicant1.Interface.Mesh dbus_property=MeshPeers getter failed
Jan 01 09:01:42 a kernel: dce: dce_client_ipc_wait:377  Client [0] unexpected err: [-110]
Jan 01 09:01:42 a kernel: dce: dce_ipc_send_message_sync:569  Error in waiting for ack
Jan 01 09:01:42 a kernel: NVRM: GPU0 dceclientSendRpc_IMPL: Send RPC failed for clientId 2147483648 error 4294967186
Jan 01 09:01:42 a kernel: NVRM: GPU0 _dceRpcIssueAndWait: NVRM_RPC_DCE: Error while issuing RPC [0xffffff92]
Jan 01 09:01:42 a systemd-resolved[509]: Using degraded feature set TCP instead of UDP for DNS server 8.8.8.8.
Jan 01 09:01:43 a wpa_supplicant[1676]: dbus: fill_dict_with_properties dbus_interface=fi.w1.wpa_supplicant1.Interface.Mesh dbus_property=MeshPeers getter failed
Jan 01 09:01:45 a dhcpd[2003]: DHCPREQUEST for 192.168.55.100 from 5e:8f:e2:0d:b2:b8 (System-Product-Name) via l4tbr0
Jan 01 09:01:45 a dhcpd[2003]: DHCPACK on 192.168.55.100 to 5e:8f:e2:0d:b2:b8 (System-Product-Name) via l4tbr0
Jan 01 09:01:46 a wpa_supplicant[1676]: dbus: fill_dict_with_properties dbus_interface=fi.w1.wpa_supplicant1.Interface.Mesh dbus_property=MeshPeers getter failed
Jan 01 09:01:46 a sudo[2386]: pam_unix(sudo:session): session closed for user root
Jan 01 09:01:49 a wpa_supplicant[1676]: dbus: fill_dict_with_properties dbus_interface=fi.w1.wpa_supplicant1.Interface.Mesh dbus_property=MeshPeers getter failed
Jan 01 09:01:52 a kernel: dce: dce_client_ipc_wait:377  Client [0] unexpected err: [-110]
Jan 01 09:01:52 a kernel: dce: dce_ipc_send_message_sync:569  Error in waiting for ack
Jan 01 09:01:52 a kernel: NVRM: GPU0 dceclientSendRpc_IMPL: Send RPC failed for clientId 2147483648 error 4294967186
Jan 01 09:01:52 a kernel: NVRM: GPU0 _dceRpcIssueAndWait: NVRM_RPC_DCE: Error while issuing RPC [0xffffff92]
Jan 01 09:01:52 a kernel: dce: dce_ipc_send_message:484  Error getting next free buf to write
Jan 01 09:01:52 a kernel: dce: dce_ipc_send_message_sync:561  Error in sending message to DCE
Jan 01 09:01:52 a kernel: NVRM: GPU0 dceclientSendRpc_IMPL: Send RPC failed for clientId 2147483648 error 4294967268
Jan 01 09:01:52 a kernel: NVRM: GPU0 _dceRpcIssueAndWait: NVRM_RPC_DCE: Error while issuing RPC [0xffffffe4]
Jan 01 09:01:52 a kernel: dce: dce_ipc_send_message:484  Error getting next free buf to write
Jan 01 09:01:52 a kernel: dce: dce_ipc_send_message_sync:561  Error in sending message to DCE
Jan 01 09:01:52 a kernel: NVRM: GPU0 dceclientSendRpc_IMPL: Send RPC failed for clientId 2147483648 error 4294967268
Jan 01 09:01:52 a kernel: NVRM: GPU0 _dceRpcIssueAndWait: NVRM_RPC_DCE: Error while issuing RPC [0xffffffe4]

Notes on the log

The fault is reported by the dce-fabric error monitor, but the decoded
target is “Fabric: cbb-fabric”, “Slave_Id: 0x37”, with MASTER_ID = DCE
performing a Write to 0x13806540. Since 0x13800000 is the display
controller aperture on Tegra234, this looks like DCE writing to a display
register and being rejected.

The faulting address is not always the same. On an earlier run, in a
different software configuration, I saw the identical failure sequence at
0x13806d40, so the offset within the display aperture appears to vary
between occurrences while everything else stays the same.

The SLAVE_ERR is immediately followed by “DCE ucode abort occurred”, and
from that point DCE never comes back. About ten seconds later
dce_client_ipc_wait times out with -110 and the NVRM RPC fails with
0xffffff92. Ten seconds after that the same timeout repeats, and this time
the IPC layer also reports “Error getting next free buf to write” with the
RPC failing as 0xffffffe4, which suggests the IPC buffers are now
exhausted because nothing on the DCE side is consuming them. The failures
continue from there and the display stack stays dead until reboot.

On the earlier run I mentioned above, a few seconds before the fault
nvidia-modeset had also reported “unknown DPCD revision 0.0” on the MST
path, together with a failing RM control call to DCE. That message is not
present in the attached log, so the preceding symptoms seem to vary, but
the SLAVE_ERR followed by the DCE ucode abort is consistent every time.

On the supported-configuration question

I am aware of this earlier topic, where a DP hub configuration on Orin NX
was stated to be unsupported:

I understand that a DP MST hub may still be outside the supported
configurations, and I am not asking you to validate the hub itself. My
concern is that an external device on the DP link can drive the DCE
firmware into an unrecoverable state on otherwise stock hardware and
software. In the field, any DP device or cable event is outside our
control, so this looks like a robustness issue rather than only a hub
compatibility issue.

Questions

  1. Is a DP MST hub configuration supported on Orin Nano in JetPack 7.2.1?
    If not, is there an officially recommended way to drive HDMI displays
    from the Orin Nano DP output? Only one monitor is connected in this
    test; the hub is in the path because it reflects the configuration we
    are evaluating.
  2. Should any hotplug event, valid or not, be able to leave DCE in an
    unrecoverable aborted state? This reproduces on a clean flash with the
    sample rootfs, so no application code is involved.
  3. Is there any way to reset or restart DCE after “DCE ucode abort
    occurred” without rebooting the system? A reboot is not always an
    acceptable recovery path for us.
  4. Is there any workaround or setting that prevents the SLAVE_ERR in the
    first place?
  5. What does Slave_Id 0x37 on cbb-fabric correspond to in R39.2.1? The
    faulting address differs between occurrences (0x13806540 and
    0x13806d40), so knowing which block this is would help.

Attached log

The attached log is the full journal from the run where the failure
occurred, captured on the clean sample rootfs image. It includes userspace
messages as well as kernel messages. I can also provide a serial console
log including the UEFI/MB2 stage if that would help.

Thank you.

log.txt (298.4 KB)

4

Hi, just following up on this one.

I realise I asked several questions at once, which may have made this
harder to answer. If it helps, the one that matters most to us is
question 3: whether there is any way to recover DCE after “DCE ucode
abort occurred” without a full reboot. Even a “no, a reboot is the only
way” would be useful for us to know, so that we can plan around it.

Thank you.

7

Hi @masai,

Thank you for the detailed report and follow-up.
We will investigate this issue internally, with a focus on your question about recovering DCE after the abort without a full system reboot.

Thanks.

8

Btw, to help with the investigation, please reproduce the issue and, before rebooting, connect to the Jetson via SSH and run:

sudo cat /sys/kernel/debug/tegra_dce/dce_logs/logs > dce-enc.log

Please upload the original dce-enc.log file as an attachment for internal analysis. Binary content is expected. If the command fails or the file is empty, please let us know and include any error message.

9

Thank you. I reproduced the failure and captured the DCE log over SSH
before rebooting, as instructed. The command succeeded and the resulting
file has content, so it is not empty. It is attached as requested.

dce-enc.log (25.5 KB)

This run shows the same signature as before: a dce-fabric SLAVE_ERR with
MASTER_ID = DCE writing to 0x13806540, immediately followed by “DCE ucode
abort occurred”, then the -110 timeouts in dce_client_ipc_wait and the
failing NVRM RPCs. The display did not recover.

The faulting address this time is 0x13806540, the same as in my first
post. Combined with the 0x13806d40 I mentioned seeing on an earlier run,
the address does not appear to be random - it seems to take one of a
small number of values.

The kernel log excerpt for this run is below, so you can line it up with
the DCE log. Note that this capture is from the same developer kit but
with a freshly reflashed image, so the hostname in the log differs from
my first post. The failure reproduces the same way after the reflash.

Jan 01 09:06:15 admin systemd-resolved[475]: Using degraded feature set UDP instead of TCP for DNS server 8.8.8.8.
Jan 01 09:06:17 admin kernel: CPU:0, Error: dce-fabric@0xde00000, irq=32
Jan 01 09:06:17 admin kernel: **************************************
Jan 01 09:06:17 admin kernel: CPU:0, Error:dce-fabric, Errmon:2
Jan 01 09:06:17 admin kernel:           Error Code                : SLAVE_ERR
Jan 01 09:06:17 admin kernel:
Jan 01 09:06:17 admin kernel:           Error Code                : SLAVE_ERR
Jan 01 09:06:17 admin kernel:           MASTER_ID                : DCE
Jan 01 09:06:17 admin kernel:           Address                : 0x13806540
Jan 01 09:06:17 admin kernel:           Cache                        : 0x1 -- Bufferable
Jan 01 09:06:17 admin kernel:           Protection                : 0x3 -- Privileged, Non-Secure, Data Access
Jan 01 09:06:17 admin kernel:           Access_Type                : Write
Jan 01 09:06:17 admin kernel:           Access_ID                : 0x0
Jan 01 09:06:17 admin kernel:           Fabric_Id                : 0x0
Jan 01 09:06:17 admin kernel:           Fabric                : cbb-fabric
Jan 01 09:06:17 admin kernel:           Slave_Id                : 0x37
Jan 01 09:06:17 admin kernel:           Burst_length                : 0x0
Jan 01 09:06:17 admin kernel:           Burst_type                : 0x1
Jan 01 09:06:17 admin kernel:           Beat_size                : 0x2
Jan 01 09:06:17 admin kernel:           VQC                        : 0x0
Jan 01 09:06:17 admin kernel:           GRPSEC                : 0x3f
Jan 01 09:06:17 admin kernel:           FALCONSEC                : 0x0
Jan 01 09:06:17 admin kernel:         **************************************
Jan 01 09:06:17 admin kernel: dce: dce_handle_irq_status:272  DCE ucode abort occurred
Jan 01 09:06:20 admin systemd-resolved[475]: Using degraded feature set TCP instead of UDP for DNS server 8.8.8.8.
Jan 01 09:06:27 admin kernel: dce: dce_client_ipc_wait:377  Client [0] unexpected err: [-110]
Jan 01 09:06:27 admin kernel: dce: dce_ipc_send_message_sync:569  Error in waiting for ack
Jan 01 09:06:27 admin kernel: NVRM: GPU0 dceclientSendRpc_IMPL: Send RPC failed for clientId 2147483648 error 4294967186
Jan 01 09:06:27 admin kernel: NVRM: GPU0 _dceRpcIssueAndWait: NVRM_RPC_DCE: Error while issuing RPC [0xffffff92]
Jan 01 09:06:30 admin systemd-resolved[475]: Using degraded feature set UDP instead of TCP for DNS server 8.8.8.8.
Jan 01 09:06:35 admin systemd-resolved[475]: Using degraded feature set TCP instead of UDP for DNS server 8.8.8.8.
Jan 01 09:06:36 admin sudo[7862]: pam_unix(sudo:session): session closed for user root
Jan 01 09:06:37 admin kernel: dce: dce_client_ipc_wait:377  Client [0] unexpected err: [-110]
Jan 01 09:06:37 admin kernel: dce: dce_ipc_send_message_sync:569  Error in waiting for ack
Jan 01 09:06:37 admin kernel: NVRM: GPU0 dceclientSendRpc_IMPL: Send RPC failed for clientId 2147483648 error 4294967186
Jan 01 09:06:37 admin kernel: NVRM: GPU0 _dceRpcIssueAndWait: NVRM_RPC_DCE: Error while issuing RPC [0xffffff92]
Jan 01 09:06:37 admin kernel: dce: dce_ipc_send_message:484  Error getting next free buf to write
Jan 01 09:06:37 admin kernel: dce: dce_ipc_send_message_sync:561  Error in sending message to DCE
Jan 01 09:06:37 admin kernel: NVRM: GPU0 dceclientSendRpc_IMPL: Send RPC failed for clientId 2147483648 error 4294967268
Jan 01 09:06:37 admin kernel: NVRM: GPU0 _dceRpcIssueAndWait: NVRM_RPC_DCE: Error while issuing RPC [0xffffffe4]
Jan 01 09:06:37 admin kernel: dce: dce_ipc_send_message:484  Error getting next free buf to write
Jan 01 09:06:37 admin kernel: dce: dce_ipc_send_message_sync:561  Error in sending message to DCE
Jan 01 09:06:37 admin kernel: NVRM: GPU0 dceclientSendRpc_IMPL: Send RPC failed for clientId 2147483648 error 4294967268
Jan 01 09:06:37 admin kernel: NVRM: GPU0 _dceRpcIssueAndWait: NVRM_RPC_DCE: Error while issuing RPC [0xffffffe4]
10

Thanks for the log.
We may take some time to investigate this issue.
Once we have some findings, we will update you here.

Thanks.

12

Hi @masai ,

We haven’t been able to reproduce the issue consistently so far. You mentioned that slow insertion triggers it every time. Could you share the number of failures out of the total unplug/replug attempts (for example, 10 failures in 10 attempts)?

If you also have results for normal-speed reconnections, please share those counts as well.

Thanks.

15

Thanks for looking into this. Let me correct something from my first
post, which was probably misleading.

When I wrote that it reproduces 100% of the time, I should have been
more precise. What I meant was that it is reliably reproducible, not
that every single attempt fails. Once I am deliberately aiming for the
slow insertion, I can usually trigger it within about three attempts.
So the reproduction rate is high, but it does take a few tries to hit
the right movement.

I cannot give you a clean count out of a fixed number of attempts,
because once it fails the display never comes back, so I have to reboot
before I can try again. That makes it awkward to express as “N failures
out of N attempts” in a continuous run.

For normal-speed reconnection, I have never seen it fail. This matches
what I said earlier - at normal speed the display recovers every time.

On what “slow” means: I find this hard to put into exact numbers,
because it is something I do by feel. The closest description I can
give is that I move the connector very gently through the point where
the DP link is on the edge of being detected - slowly enough that the
link sits in that ambiguous state for a moment, rather than making or
breaking cleanly. Both pulling out and pushing in are done that way.

17

Ok. Understood. We have just reproduced successfully.
I will update you as soon as there is any progress.