Jetson AGX Orin: Intermittent Xorg NVIDIA Driver Initialization Failure - Software Rendering (llvmpipe) and GStreamer FPS Drops

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
,
1

Platform: NVIDIA Jetson AGX Orin
JetPack / L4T version: 7.2 L4T39.2
Display server: Xorg
Graphics stack: NVIDIA Tegra (nvgpu), EGL/GLX, Mesa
GStreamer: 1.24.2

Issue Description

We are experiencing an intermittent graphics initialization issue on our Jetson AGX Orin. During some boots, Xorg fails to initialize the NVIDIA graphics driver and falls back to the modesetting driver with Mesa software rendering (llvmpipe). During normal boots, Xorg initializes the NVIDIA driver correctly.

This affects our GStreamer camera streaming performance. We also observed that switching the NVIDIA power mode sometimes restores the expected streaming performance.

Observed Behavior

We compared the Xorg logs and graphics renderer information between a bad boot and a good boot.

Parameter Bad boot Good boot
Xorg startup Approximately 19.5 seconds Approximately 23.9 seconds
NVIDIA probe (EE) No devices detected. NVIDIA driver initializes
Fallback driver modeset(0) No fallback observed
GLX provider DRISWRAST NVIDIA
OpenGL renderer llvmpipe NVIDIA Tegra Orin (nvgpu)
GStreamer performance FPS drops observed Expected FPS

The bad boot also produces the following warning:

libEGL warning: DRI3 error: Could not get DRI3 device
libEGL warning: Ensure your X server supports DRI3 to get accelerated rendering

In the bad state, Xorg appears to fall back to software rendering. We suspect that this may contribute to the GStreamer performance degradation, but we would like NVIDIA to confirm whether this is the expected behavior and whether it explains our observations.

Recovery Behavior

We have observed two ways to recover the expected performance:

  1. Restarting the display manager:
sudo systemctl restart display-manager
  1. Switching the NVIDIA power mode using nvpmodel.

Restarting the display manager restores NVIDIA rendering and the expected camera streaming performance.

However, we have not yet confirmed whether switching power mode restores the NVIDIA renderer itself or only improves performance while software rendering remains active.

The NVIDIA device nodes are present in both the good and bad states, and nvidia_drm reports modesetting enabled.

Questions for NVIDIA

  1. What could cause Xorg to intermittently report No devices detected for the NVIDIA graphics device on Jetson AGX Orin, even when the NVIDIA device nodes exist?

  2. Is this a known issue related to the timing of NVIDIA kernel driver initialization, nvidia_drm, EGL/GLX initialization, or Xorg startup?

  3. Is there a recommended systemd dependency or startup-ordering configuration to ensure that the NVIDIA graphics stack is fully initialized before the display manager starts?

  4. Why might switching nvpmodel power mode restore the expected performance without an explicit display-manager restart? Can power-mode switching trigger any relevant GPU or graphics-driver reinitialization?

  5. What is the recommended permanent fix to prevent Xorg from falling back to modeset and Mesa software rendering on some boots?

  6. Are there specific NVIDIA services, kernel logs, or diagnostic commands we should collect to identify the component that fails during initialization?

We would appreciate NVIDIA’s guidance on identifying the root cause and implementing a reliable permanent fix.

Thank you.

5

Hi,

Please try patch and check whether the issue still observed.

diff --git a/etc/systemd/nv-load-display-modules.sh b/etc/systemd/nv-load-display-modules.sh
--- a/etc/systemd/nv-load-display-modules.sh
+++ b/etc/systemd/nv-load-display-modules.sh
@@ -173,6 +173,14 @@
 # are also loaded when nvidia is pulled in as a dependency.
 modprobe nvidia_drm
 
+if [[ "${variant}" == *nvgpu* ]]; then
+	if ! command -v udevadm >/dev/null 2>&1; then
+		echo "WARNING: udevadm not found; skipping GPU wait." >&2
+	elif ! udevadm wait --timeout=30 /dev/nvhost-gpu; then
+		echo "WARNING: Timed out waiting for /dev/nvhost-gpu; continuing." >&2
+	fi
+fi
+
 echo "Loaded display stack (variant=${variant}," \
 	"depmod=${src_depmod}," \
 	"modprobe=${src_modprobe})."

Thanks

6

Hi,

The issue has occurred again during boot. In the bad state, the nv-load-display-modules.service log contains the following warning:

WARNING: Timed out waiting for /dev/nvhost-gpu; continuing.

I also verified the issue using glxinfo -B. The NVIDIA renderer does not initialize correctly in the bad state, whereas it works correctly in the good state.

I have collected the following logs from both states for comparison:

  1. bad_state_full_boot.log - Complete journal for the bad boot.

  2. bad_state_nv-load-display-modules.log - Display-module service journal for the bad boot.

  3. good_state_full_boot.log - Complete journal for the good boot.

  4. good_state_nv-load-display-modules.log - Display-module service journal for the good boot.

I have included all four log files, along with the modified nv-load-display-modules.sh script, in the attached nvidia_renderer_logs.zip file.

nvidia_renderer_logs.zip (136.0 KB)

Could you please review the logs and script to help identify why /dev/nvhost-gpu intermittently fails to become available within the timeout and why the NVIDIA renderer fails to initialize in the bad state?

Regards,

Govarthana

7

Hi,
When the error occurs, please run the commands and see if the system is back to normal:

$ sudo systemctl stop gdm
$ sudo systemctl start gdm
8

Hi @DaneLLL ,

When the issue occurs, I can restore the system to its normal state by stopping and restarting GDM using the following commands:

$ sudo systemctl stop gdm
$ sudo systemctl start gdm

I’m attaching the logs below for your reference

nvidia_renderer_logs_2.zip (87.5 KB)

Could you please analyze the logs and help us identify the root cause of this intermittent issue and provide a permanent fix to prevent the NVIDIA renderer from failing to initialize after boot?

We would like to resolve the underlying issue rather than rely on restarting GDM as a workaround.

Looking forward to your analysis and recommendations.