My ThinkPad P15 Gen2 recently gained a Fedora 44 side (that story and its NVIDIA sequel are both on this site), and it came with one shadow: the machine would crash on resume from sleep. Not every time — the worst kind of bug — but often enough that suspending the laptop felt like a coin toss. For a machine whose whole Linux purpose is being closed, carried to a coffee shop, and reopened, that’s not a quirk. That’s a dealbreaker.
Naming the beast
The journal from a crashed boot told the story precisely. On resume, the NVIDIA driver hit a NULL pointer dereference in a function called nvEvoDisableVblankSemControl — a known regression in the 610.4x driver series affecting Ampere mobile GPUs like my RTX A5000. If you found this article by googling that function name from your own crash log: yes, it’s the driver, no, it’s not your configuration, and there’s good news below.
The conventional mitigations for NVIDIA sleep trouble are worth knowing, because they’re the fallback if you’re stuck on an affected driver:
- Enable NVIDIA’s suspend orchestration services, which save and restore GPU state properly across sleep:
sudo systemctl enable nvidia-suspend.service nvidia-resume.service nvidia-hibernate.service- Tell the driver to preserve video memory allocations across suspend, via a file at
/etc/modprobe.d/nvidia-sleep.confcontaining:
options nvidia NVreg_PreserveVideoMemoryAllocations=1…followed by sudo dracut --force to rebuild the initramfs so it applies from early boot, and a reboot.
The discipline: baseline before mitigation
I had those mitigations queued up and ready. Then a routine dnf update arrived carrying a new kernel and a new driver: 610.57.04. And here’s the step I’d argue matters more than any config file: I tested the new driver unmodified before applying anything.
Why? Because if you apply mitigations and update at the same time and the crash disappears, you’ve learned nothing. Was it the fix? The driver? Both? You’ll carry those config changes forever, cargo-cult style, never knowing if they were needed. Change one variable at a time — the oldest rule in debugging, and the easiest one to abandon when you just want your laptop to work.
The verdict
Update applied, reboot, sleep… and the machine woke as if there had never been a problem. One wake is an anecdote, though, so I put it through a proper gauntlet: several rapid sleep/wake cycles (which stress the vblank path nicely), cycles on mains and on battery (power-state transitions differ between them), and the real-world test — boot at home, sleep, cycle to a coffee shop, wake half an hour later on a different WiFi network. Every wake clean. The journal after each one, checked with
journalctl -b -k | grep -iE "nvEvo|null pointer|Oops"came back silent — which matters, because a caught kernel oops can lurk in the log with the GPU limping along even when the desktop seems to have survived. Silence in that grep is the real confirmation.
The fix, in the end, was a driver update and patience. NVIDIA repaired the regression upstream; 610.57.04 sleeps and wakes reliably on my A5000. The mitigation config sits unused in my notes — documented, in case a future regression brings it back into fashion, but not installed. My system stays vanilla, which means the next time something breaks, there’s one less variable to rule out.
The rolling-release bargain
There’s a lesson here I keep re-learning with Fedora. Being cutting-edge cuts both ways: you get tomorrow’s fixes early, and occasionally today’s bugs early too. On my HP Z840 I’ve had update-induced issues where the winning move was restoring a CloneZilla backup, skipping that update for a few weeks, and carrying on working. A month later the same update applied cleanly — the bug had been found and fixed while I got on with my life.
Snapshots and patience are the price of admission for a rolling-edge distro, and honestly it’s a fair price. Btrfs snapshots via snapper mean a bad update is a two-minute rollback rather than a lost weekend, and “wait a few weeks” is a legitimate engineering strategy, not an admission of defeat. Sometimes the best fix is the one somebody else is already working on, and our job is simply to stay recoverable until it ships.
So if your Ampere-generation laptop crashes on resume and your driver version starts with 610.4: update first, test unmodified, and only then reach for the config files. The bug you’re fighting may already be dead.