The 5-Minute Display Lockup: Tracing a 4-Layer Linux Bug Across NVIDIA, GNOME, RPM Fusion, and systemd

The Symptom

On modern hybrid-GPU workstations (Intel/AMD integrated graphics paired with a discrete NVIDIA RTX card running Wayland under GNOME), users reported an unsettling failure pattern: exactly 5 minutes (300 seconds) after display sleep or system inactivity, the entire graphics compositor froze solid.

The mouse pointer might occasionally respond, but the framebuffer rendered no new frames. SSH remained operational, but any attempt to interact with /dev/dri/card* or query nvidia-smi caused process deadlocks in uninterruptible sleep state (D-state).

The Architectural Scope

Isolating this bug required peeling back four distinct layers in the modern Linux desktop ecosystem:

1. Layer 1: The Linux DRM / KMS Subsystem & NVIDIA Kernel Module (nvidia-drm, nvidia.ko)
2. Layer 2: The Wayland Compositor (Mutter / GNOME Shell) managing atomic modesetting and buffer flipping
3. Layer 3: The System Init & Power State Daemon (systemd-logind and power management targets)
4. Layer 4: Packaging and Driver Scripts (RPM Fusion packaging logic for dynamic power management rules)

Diagnosing the 300-Second Trigger

In systems programming, exact round numbers like 300 seconds are rarely coincidences. They almost always point to a timer, timeout, or autosuspend delay.

Using udevadm and checking runtime power management attributes revealed:

# Querying device power management attributes
cat /sys/bus/pci/devices/0000:01:00.0/power/autosuspend_delay_ms
# Output: 300000 (Exactly 300,000 ms = 5 minutes!)

The discrete NVIDIA GPU had a runtime power management autosuspend threshold configured for 300,000 milliseconds.

When 5 minutes elapsed with no active 3D rendering context:

1. The kernel PM subsystem signaled the device to enter low-power state D3hot or D3cold.
2. The proprietary driver initiated power-down sequencing.
3. However, Mutter (GNOME's Wayland compositor) still held an open DRM lease and direct buffer scans for external display heads routed through the discrete GPU.
4. When Mutter attempted the next atomic commit, the kernel waited for the GPU to power up, but the hardware power state state-machine was locked in an unhandled transition state.

Why Wayland Made It Harder to Debug

Under legacy X11, the display server ran as root with direct, unmanaged access to video hardware. Under Wayland:

• The compositor runs as an unprivileged user session.
• Access to DRM master privileges is brokered by systemd-logind.
• NVIDIA proprietary drivers rely on a combination of nvidia-powerd, nvidia-suspend.service, nvidia-resume.service, and memory allocation preservation across suspend via /proc/driver/nvidia/suspend/allocations.

If the RPM Fusion service unit files are mismatched with the driver revision, or if NVreg_PreserveVideoMemoryAllocations=1 is not correctly coordinated with systemd-sleep, the compositor's VRAM allocations become invalid while the compositor still thinks they are resident.

The Reproduction Suite

To definitively verify the issue across hardware variations, we engineered an automated reproduction and diagnostics test suite in hybrid-gpu-wayland-freeze.

The harness performs:

• Tracepoint Capture: Logging drm:* and sys_enter events right up to the lockup point.
• Autosuspend Forcing: Programmatically reducing autosuspend_delay_ms from 300000 to 5000 to trigger the failure mode in 5 seconds instead of 5 minutes.
• VRAM Integrity Validation: Testing whether buffer handles survived dynamic power state transitions.

The Solution & Takeaways

The permanent resolution required coordinated fixes:

1. Dynamic Power Management Rule Tuning: Establishing proper udev rules to prevent D3cold transitions when connected display heads are bound to the secondary GPU.
2. systemd Service Synchronization: Ensuring nvidia-suspend and nvidia-resume units order strictly relative to systemd-logind session locking.
3. Compositor Fallback Handling: Patching the compositor's atomic commit failure handling to avoid permanent blocking in event loop iterations.

Core Lesson for Systems Engineering

High-level application performance frequently depends on low-level OS mechanics. Whether developing cloud-native distributed platforms or local developer tools, true architectural resilience demands understanding the entire stack down to kernel timers and hardware power registers.