Why KDE Plasma Survives the NVIDIA Linux Suspend Mess (and Most Other Desktops Often Don't)
Every modern NVIDIA GPU on Linux fires the GSP firmware heartbeat bug on every suspend right now — across Ubuntu, Fedora, Mint, and Arch. Whether you experience it as a zombie wake depends almost entirely on your compositor. KWin retries until the firmware recovers. Mutter often gives up. Real data, sourced reports, and an open-source logger you can run on your own machine.
Why KDE Plasma Survives the NVIDIA Linux Suspend Mess (and Most Other Desktops Often Don’t)
If you run Linux on NVIDIA hardware in 2026, you have probably hit it at least once. You close your laptop, walk away, come back, and the screen never recovers. Black panel. Backlit keyboard responsive but useless. The only path forward is the power button.
You are not alone. You are not unlucky. Your GPU is not faulty. Your distro has not been mis-configured. What you have hit is a class of bug that has been quietly accumulating across NVIDIA’s open kernel driver for months, affects every modern Ampere, Ada Lovelace, and Blackwell GPU, and currently has dozens of open issue reports across NVIDIA’s own GitHub tracker, the NVIDIA developer forums, the Arch and Ubuntu and Fedora and Mint communities, and laptop-specific forums like the Framework Community.
What this article is about: the real, present, ongoing state of NVIDIA suspend/resume on Linux in mid-2026. Why every Linux desktop is affected at the driver level, but only some compositors hide it from you. Why a small open-source tool (Zombie Event Log) helps you measure what is actually happening on your own machine — without changing it. And why, if you have to run NVIDIA on Linux right now and want fewer surprises, the most honest recommendation is to install Kubuntu and use KDE Plasma.
The Bug Class — One Symptom, Many Reports
The kernel signature is the same across reports. After resume from suspend, sometimes immediately, sometimes after a long nap:
NVRM: _kgspIsHeartbeatTimedOut: Heartbeat timed out
NVRM: _kgspRpcRecvPoll: GSP RM heartbeat timed out
A small but growing pile of GitHub issues against NVIDIA’s open kernel module documents the problem across multiple GPU generations and multiple recent driver releases:
- Issue #1086 — RTX 5070 Ti Mobile (Blackwell GB205M), GSP RM heartbeat timeout on cold boot after long power-off. Reproducible across drivers 595.45.04, 595.58.03, and 590.48.01. Open as of late March 2026.
- Issue #1064 — RTX PRO 1000 Blackwell laptop, GSP heartbeat stuck at 0 with S0ix power management. Heartbeat counter never increments since boot.
- Issue #1080 — RTX 5090 (GB202), GSP heartbeat timeout leading to Xid 109/8 under Vulkan via Proton. Confirmed on both 595.58.03 and 590.48.01.
- Issue #1117 — Blackwell RTX 50-series, s2idle resume hangs on Linux 7.0 kernel; same driver version works on 6.17. Both 580.142 and 595.58.03 reproduce the issue.
- Issue #1059 — Reloading
nvidia_drmbreaks power management entirely ifnvidia-powerdis stopped. - Issue #446 — “Timeout waiting for RPC from GSP” — older issue, still attracting reports.
NVIDIA’s own developer forum has a parallel corpus. A March 2026 thread titled “GSP-RM firmware bug: heartbeat stops after GC6 exit, leads to fatal GPU loss (Xid 79) and broken display recovery” describes the exact same failure pattern, framed as a firmware-level issue. The user reports that the heartbeat “stops” mid-session, with no recovery short of a reboot.
Distribution forums show the consumer side of the same story. The Arch Linux Forum thread on nvidia-open 565 black screens after wake-up runs to many pages. The Linux Mint Forum thread on NVIDIA + suspend session problems is a multi-year saga. The Framework Community thread — “FW16 with NVIDIA suspend/resume seems broken on Ubuntu 26.04” — is from this year, on currently-shipping hardware.
Ubuntu 26.04 LTS, Fedora 44, Linux Mint 22, openSUSE Tumbleweed, Arch — different distros, same bug. It is upstream of all of them.
What’s Actually Happening — The GSP Handshake
Every modern NVIDIA GPU contains a small embedded microcontroller called the GPU System Processor, or GSP. It runs its own firmware on the same silicon as the graphics cores. Its job is to manage power states, clocks, and selected context-switching duties — including holding the GPU’s state safely while the rest of the system sleeps.
When the kernel asks the GPU to suspend (because you closed the lid, hit Win+L, or let auto-suspend fire), the open driver delegates state preservation to GSP. The kernel effectively says “GSP, hold this. I’ll be back.”
On resume, the kernel pings GSP via an RPC (remote procedure call) heartbeat. GSP firmware is supposed to respond within 5,200 milliseconds. The handshake confirms the firmware is alive and ready to hand the GPU’s state back.
That handshake is what’s failing. The 5.2-second window expires with the heartbeat counter still at zero. The driver gives up. The DRM device — your kernel’s handle to the GPU — becomes inaccessible. KMS (kernel mode-setting) atomic operations now return errors. Anything trying to render against the GPU sees GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT, EINVAL, “GPU has fallen off the bus” Xid messages, and various flavours of dead-state cascades.
Crucially, on Blackwell hardware (RTX 50-series and newer professional cards), GSP cannot be disabled. The old nvidia.NVreg_EnableGpuFirmware=0 workaround that pre-Blackwell users sometimes leaned on is no longer available. GSP is mandatory. If GSP firmware misbehaves, you cannot opt out.
NVIDIA’s Response — One Fix, More Bugs
On 28 April 2026, NVIDIA released driver 595.71.05 with a single bug fix called out in the changelog: a Wayland resume restoration bug that left OpenGL applications staring at a black rendering surface after suspend. The fix forces the driver to correctly restore framebuffer mappings and shader caches during resume.
That sounds like the answer. It is part of the answer.
Two problems remain.
First, as of early May 2026, that fix has not yet landed in most distribution repositories. Ubuntu 26.04 still ships 595.58.03 in restricted/main and restricted/updates. Fedora’s main repos and the RPM Fusion mirror still show the older build. Arch’s nvidia-open package was updated, but reaching the broader Linux ecosystem typically takes several weeks. So the population of users actually running 595.58.03 today — the version with the bug — is enormous.
Second, even users who have moved to 595.71.05 are still reporting suspend-adjacent failures. NVIDIA Developer Forums has a thread from late April 2026 titled “Graphical corruption after suspend/resume with NVIDIA Xid 13 (595.71.05)”. The Xid 13 (graphics-engine error) corruption appears specifically on Fedora 44 with KDE Plasma 6.6.4 on Wayland, after S3 resume — meaning the new fix doesn’t address every flavour of the bug class, only the OpenGL framebuffer one.
The honest summary: NVIDIA is patching what they can find, but the bug class is broad, the firmware is opaque, and “fixed in 595.71.05” does not mean “your suspend now works on every machine.”
Why Every Linux User Hits This — But Only Some Notice
Here is the part most online discussion gets wrong.
The bug fires at the driver level. Every Linux user with affected NVIDIA hardware is hitting it on every suspend. Whether you experience it as a zombie wake depends almost entirely on your compositor — the program that draws your windows and talks to the GPU after resume.
When the GSP handshake fails, the DRM device returns errors to whatever tries to use it. On Linux today, the compositor is the first thing to try. What the compositor does next determines whether the user sees a smooth wake or a black-screen disaster.
KWin (the compositor inside KDE Plasma) is unusually aggressive about retrying broken DRM operations. When drmModeAtomicCommit returns EINVAL or the framebuffer comes back as incomplete, KWin does not crash, does not show an error dialog, does not give up. It just tries again. And again. Tens of times. Each retry is a cheap ioctl into the kernel. While that storm of retries is happening, GSP firmware silently times itself out and reinitialises in the background. Eventually one of the retries hits a moment when GSP has come back to life. The atomic modeset succeeds. The framebuffer is valid. The compositor renders the next frame. And then the next. The user notices nothing.
Mutter (the compositor inside GNOME Shell) does not have the same retry-and-recover pattern. When mutter’s KMS backend sees a broken DRM context post-resume, it tends to declare defeat — the screen stays dark, the session is unusable, and the user reaches for the power button. The Arch Linux Forum thread “Resume from suspend crashing on Nvidia + GNOME + Wayland” is one of many records of this asymmetry. Solutions in those threads typically involve manually sending GNOME Shell a STOP signal before suspend and a CONT signal after resume — i.e. forcing the compositor to skip the post-resume render attempt entirely.
Muffin (Cinnamon, Linux Mint) inherits much of mutter’s KMS plumbing as a fork; reports from Mint forums show similar patterns.
Sway, Hyprland, and other wlroots-based compositors vary. wlroots itself does retry KMS operations, but the recovery loop is less battle-tested against this specific firmware-handshake failure mode than KWin’s.
The clearest single piece of public evidence for KWin’s resilience is also the clearest single piece of evidence for mutter’s brittleness: same GPU, same kernel, same NVIDIA driver, completely different user experiences. Many people who have switched from Ubuntu/GNOME to Kubuntu/KDE on the same NVIDIA hardware describe it as “the suspend bug went away” — but technically the bug did not go away. The compositor stopped exposing it.
A Logger, Not a Fix — Zombie Event Log
Building anecdotes into evidence requires data. That is where Zombie Event Log comes in.
Zombie Event Log is a small open-source tool, MIT licensed, that hooks into systemd’s suspend/resume signal and records every cycle on your machine. It reads the system journal slice covering each suspend, classifies the outcome (clean / rescued / catastrophic), and tells you whether your compositor recovered or left you with a broken state.
It does not fix anything. It is not a workaround. It is a logger — passive, install-once, query-when-curious. The point is to make the invisible parts of suspend/resume visible: how often the bug fires on your hardware, how often your compositor saves you from it, and what the failure profile looks like when it doesn’t.
Two real cycles from a Kubuntu 26.04 workstation (RTX 3060, kernel 7.0.0-15-generic, NVIDIA open 595.58.03) tell the pattern in numbers. Both cycles fired the GSP heartbeat bug exactly as the GitHub issues describe. Both were rescued by KWin.
| Field | Cycle 1 (89-second nap) | Cycle 2 (97-minute nap) |
|---|---|---|
| GSP heartbeat timeouts | 2 | 2 |
| DRM open failures | 8 | 6 |
| KWin atomic modeset retries | 10 | 9 |
| KWin output configuration rejections | 4 | 3 |
GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT events |
21,990 | 42,636 |
| Clean journal lines after recovery | 48,449 | 92,881 |
| Outcome | rescued (high confidence) | rescued (high confidence) |
In the second cycle, KWin attempted to render a frame against a dead GPU forty-two thousand times during the recovery storm. Then a successful render. Then ninety-two thousand journal lines of completely normal operation.
That is not a fix. The driver is still broken. The compositor is just stubborn enough to make broken not matter.
To run it on your machine:
git clone https://github.com/mmhfarooque/zombie-event-log.git
cd zombie-event-log
sudo bash install.sh
zel doctor
After installing, suspend and resume once. Then:
zel last
zel show <cycle-id>
zel stats
Data lives at /var/lib/zel/cycles/. Nothing leaves your machine. Uninstall is a single sudo bash uninstall.sh and removes everything cleanly.
If you run GNOME, Cinnamon, or any compositor other than KWin and you want to contribute to the data picture, the v0.2 mutter and muffin adapters need real ground-truth captures of compositor failures. Submit them as GitHub issues attached to the zombie-event-log repository.
The Practical Recommendation — Use Kubuntu Until Upstream Lands
If you are choosing a Linux distribution for an NVIDIA workstation or laptop in 2026 and your priority is minimum hassle around suspend, sleep, lid-close, and lock-screen wake, the most honest recommendation right now is Kubuntu (Ubuntu 26.04 LTS with the KDE Plasma 6 desktop).
Reasons, in plain terms:
- KWin’s compositor behaviour absorbs this entire class of NVIDIA driver bugs. You will still hit the bug on every suspend — the GitHub issues will not stop applying to you — but you mostly will not feel it.
- Ubuntu’s NVIDIA packaging is mature. The proprietary and open-driver branches both ship in
restricted, with kernel-module DKMS hooks, sleep services (nvidia-suspend,nvidia-resume,nvidia-hibernate), and PreserveVideoMemoryAllocations defaults pre-configured. Other distros require more manual intervention. - LTS update cadence matches upstream NVIDIA stability. When 595.71.05 lands in
restricted-updates, you get it via the standardapt upgradeflow. No PPA roulette, no manual.runinstaller. - The recommendation is reversible. If a future GNOME Shell release introduces a similarly stubborn KMS retry pattern (mutter’s maintainers have discussed this on bug trackers), or if NVIDIA’s firmware bugs are actually fixed at the source, KDE’s advantage shrinks. Today, in May 2026, it is the path of least resistance.
This is not a vote against GNOME. Mutter is excellent in many areas. But mutter’s design philosophy — fail clearly so the user notices and reports the bug upstream — collides badly with a class of driver firmware bugs the user cannot fix from userspace. KWin’s “retry until it works” philosophy hides the bug at the cost of obscuring whether you actually have one. Both are valid engineering choices. Right now, on this hardware, KWin’s choice is more useful.
If you are already on Ubuntu/GNOME and don’t want to reinstall, you can sudo apt install kde-plasma-desktop and select Plasma at the SDDM/GDM login screen. Same machine, same NVIDIA driver, dramatically different suspend reliability.
What’s Next — Watching for the Real Fix
The real fix is upstream. NVIDIA needs to ship a driver with a working GSP heartbeat across all suspend paths and all current GPU generations. 595.71.05 was a step. The pattern of new Xid 13 reports against the very fix release suggests several more steps are needed. The community has been fairly patient — there is a reason the open kernel module repository accepts issues at all.
If you want to track when the bug is actually fixed for your machine, install Zombie Event Log, suspend a few times, and watch for the day your gsp_heartbeat_timeouts count drops from 2 to 0 on every cycle. That will be the day your driver is genuinely fixed, not the day a press release claimed it was.
Until then: KDE retries. The bug fires. You wake up. Cursor blinks. Browser remembers your tabs.
You’d never know.
Repository
github.com/mmhfarooque/zombie-event-log
MIT licensed. Cross-distro (any systemd-based Linux). KWin adapter is first-class; mutter and muffin adapters are partial and accepting community evidence.
Sources
- NVIDIA Open GPU Kernel Modules — github.com/NVIDIA/open-gpu-kernel-modules
- GitHub Issue #1086, RTX 5070 Ti Mobile GSP timeout on cold boot — link
- GitHub Issue #1064, RTX PRO 1000 Blackwell GSP heartbeat stuck — link
- GitHub Issue #1080, RTX 5090 GSP timeout under Vulkan — link
- GitHub Issue #1117, Blackwell s2idle resume hangs on Linux 7.0 — link
- GitHub Issue #1059, nvidia_drm reload breaks power management — link
- GitHub Issue #446, GSP RPC timeout (long-standing) — link
- NVIDIA Developer Forums, GSP-RM firmware bug after GC6 exit — link
- NVIDIA Developer Forums, Graphical corruption after suspend on 595.71.05 — link
- Arch Linux Forums, Disabling GSP firmware on nvidia-open — link
- Arch Linux Forums, nvidia-open 565 black screen after wake-up — link
- Arch Linux Forums, Resume from suspend crashing on NVIDIA + GNOME + Wayland — link
- Linux Mint Forums, NVIDIA driver and suspend session problem — link
- Framework Community, FW16 NVIDIA suspend broken on Ubuntu 26.04 — link
- NVIDIA 595.71.05 release coverage, GamingOnLinux — link
- NVIDIA 595.71.05 changelog, UbuntuPit — link
- KWin source — invent.kde.org/plasma/kwin
- mutter source — gitlab.gnome.org/GNOME/mutter
- systemd-sleep documentation — systemd.io/SLEEP
- DRM atomic modeset API — docs.kernel.org/gpu/drm-kms.html
