NVIDIA / NVIDIA/open-gpu-kernel-modules

RTX 50-series (Blackwell): s2idle resume hangs on Linux 7.0 kernel; same driver works on 6.17

Open
#1,117 32 comments 20 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
C
Stars
17.4k
Forks
1.9k
PR merge metrics
No merged PRs in 30d

Description

NVIDIA Open GPU Kernel Modules Version

580.142

Please confirm this issue does not happen with the proprietary driver (of the same version). This issue tracker is only for bugs specific to the open kernel driver.
  • I confirm that this does not happen with the proprietary driver package.
Operating System and Version

Ubuntu 26.04 LTS Beta

Kernel Release

7.0.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC

Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.
  • I am running on a stable kernel release.
Hardware: GPU

NVIDIA GeForce RTX 5070 Laptop GPU

Describe the bug

Tested on two upstream tags; both reproduce.

Primary (currently installed, actively reproducing): 580.142

Also reproduced on: 595.58.03

Not built from source / SHA — DKMS-built from the Ubuntu-packaged upstream-tag
source tree.


## Field: Stable kernel confirmation

Confirmed. `uname -a` reports:
`Linux 7.0.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Mon Apr 13 11:09:53 UTC 2026 x86_64`
— Ubuntu's ABI-14 build of upstream stable Linux 7.0, not a `-rc`.

---

## Field: Describe the bug

The nvidia-open driver hangs during s2idle lid-close suspend on Linux
kernel 7.0. The identical driver on the identical hardware suspends and
resumes cleanly on kernel 6.17. Blacklisting all nvidia kernel modules on
kernel 7.0 also produces a clean s2idle cycle, so this is a driver-side
regression triggered by kernel changes between 6.17 and 7.0 — not a
platform or kernel-core bug. Both 580.142 and 595.58.03 reproduce.

Kernel nvidia loaded Result
6.17.0-22 yes works
6.17.0-22 no works
7.0.0-14 yes hangs
7.0.0-14 no (module_blacklist=nvidia_drm,nvidia_modeset,nvidia_uvm,nvidia) works
Failure signature

journalctl -b -1 -k of a failed boot ends with:

kernel: nvidia 0000:01:00.0: Enabling HDA controller
    (then the journal ends — the next line is the next boot after hard reset)

PM: suspend entry (s2idle) does not print. The kernel emits that
message only after dpm_suspend_start() — the device suspend cascade —
returns, so the fact that it never prints means one of the .suspend
callbacks in the cascade never returns. The last device the kernel
touched per the log is the nvidia-bound GPU function at 0000:01:00.0.

The Enabling HDA controller line itself is kernel-side, from
quirk_nvidia_hda in drivers/pci/quirks.c, and the same line also
appears on 6.17 where it's followed by a normal cycle. It's not the
problem — it's just the last log emitted before control enters the
nvidia driver's suspend path, where it never returns on 7.0.

Post-hang artifact on the next boot

dmesg on the post-reset boot shows the GSP left in an inconsistent state
from the aborted resume:

NVRM: _kgspProcessRpcEvent: Attempted to process RPC event from GPU0: 0x101a
      (PFM_REQ_HNDLR_STATE_SYNC_CALLBACK) during bootup without API lock
NVRM: nvAssertFailedNoLog: Assertion failed: 0 @ kernel_gsp.c:1446

This is a consequence of the failed resume, not the primary bug, but the
GSP PM RPC path is a plausible place to look.

Corroboration on different hardware

Another user reports the identical symptoms on a Lenovo ThinkPad T1g Gen
8 (Intel Core Ultra 9 + RTX 5070 Max-Q) with the same kernel + driver
combination on Ubuntu 26.04, ruling out platform (AMD Phoenix /
Framework) as a necessary condition:
https://forums.developer.nvidia.com/t/ubuntu-26-04-suspend-resumes-to-black-screen/365785

Tracking

Full diagnostics attached to Ubuntu Launchpad bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2149963

To Reproduce

Framework Laptop 16 with an RTX 5070 Max-Q Mobile (GB206M) and AMD
Phoenix iGPU, on Ubuntu 26.04 "resolute" (development release).

  1. Install nvidia-open:
    sudo apt install nvidia-driver-595-open
    (or nvidia-driver-580-open — both reproduce)

  2. Boot linux-image-7.0.0-14-generic with default modprobe config.
    Confirm all four nvidia kernel modules are loaded:
    lsmod | grep -E '^nvidia(_drm|_modeset|_uvm)?\b'

  3. Log in to GNOME on Wayland (AMD iGPU drives the internal display via
    amdgpu; nvidia modules are loaded for compute / offload).

  4. Close the laptop lid. Wait ~10 seconds. Open the lid.

Expected: normal s2idle resume — display re-lights, session continues,
dmesg shows PM: resume from suspend-to-idlePM: suspend exit.

Actual: display never wakes, system is unresponsive, hard reset (long
power button) is the only recovery. On the next boot, journalctl -b -1 -k ends with nvidia 0000:01:00.0: Enabling HDA controller and no
PM: suspend entry (s2idle) line.

Switching to linux-image-6.17.0-22-generic with no other changes makes
the same cycle succeed — the only variable that matters is the kernel.

Bug Incidence

Always

nvidia-bug-report.log.gz

nvidia-bug-report.log.gz

More Info

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the s2idle lid-close cycle on kernel 7.0 with the nvidia modules loaded, then compare it with kernel 6.17. Start with the suspend path for the GPU at 0000:01:00.0, the kernel-side quirk in drivers/pci/quirks.c, and the GSP PM path around kernel_gsp.c:1446. Done means the system resumes normally on kernel 7.0 with the driver loaded and without the reported hang or post-reset GSP errors.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, linux, ubuntu
Domain
operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.