**Also affected on 595.84 — different GPU generation, different kernel, different Ubuntu release.**
Re comment from Jacob Martin (2026-07-15) asking whether 595.84 fixes this: **it does not.** I hit this exact deadlock on 2026-08-24 running `nvidia-driver-595-open` **595.84-0ubuntu0.24.04.1**. My configuration differs from the original reporter's on almost every axis except the driver, which I think rules out hardware- and kernel-specificity: | | Original reporter | This report | |---|---|---| | GPU | RTX 4070 Ti (Ada, 10de:2782) | GTX 1660 SUPER (TU116/Turing, 10de:21c4) | | Ubuntu | 26.04 resolute | 24.04 noble | | Kernel | 7.0.0-27-generic | 6.8.0-138-generic | | Driver | 595.71.05 open | **595.84 open** | | Session | GNOME Wayland + Xwayland | GNOME Wayland (mutter 46.2) | Module params: `NVreg_PreserveVideoMemoryAllocations=1`, `NVreg_TemporaryFilePath=/var`, `nvidia_drm modeset=1`. `NVreg_UseKernelSuspendNotifiers` is at its default of **0**. `nvidia_drm.fbdev` is at its default of **1**. One important generalisation: in my case **the task that refused to freeze was gnome-shell itself, not Xwayland.** Both offending tasks are threads of the same gnome-shell process (tgid 7446). So the trigger is not Xwayland-specific — it is any client stuck inside the driver when the freezer runs. ## Sequence (idle-triggered suspend, GNOME `sleep-inactive-ac-timeout` 3600s) ``` 17:56:37 systemd[1]: Reached target sleep.target - Sleep. 17:56:37 systemd[1]: Finished nvidia-suspend.service - NVIDIA system suspend actions. 17:56:37 kernel: PM: suspend entry (deep) 17:56:38 kernel: Filesystems sync: 0.916 seconds 17:56:58 kernel: Freezing user space processes 17:56:58 kernel: Freezing user space processes failed after 20.006 seconds (2 tasks refusing to freeze, wq_busy=0): 17:56:58 kernel: fbcon: Taking over console 17:56:58 kernel: OOM killer enabled. 17:56:58 kernel: Restarting tasks ... done. ``` Note the kernel *correctly* aborts and thaws userspace — unrelated processes kept logging all night. `PM: suspend exit` is never reached. There is no resume; the machine simply never sleeps and the displays never light again. ## The four-way lock chain **1. gnome-shell main thread — state R, spinning inside the driver, holding `mmap_lock` for write:** ``` task:gnome-shell state:R running task pid:7446 tgid:7446 ? gvaspaceInvalidateTlb_IMPL+0xe8/0x17f [nvidia] ? gvaspaceAlloc_IMPL+0x6bc/0x9c0 [nvidia] ? dmaAllocMapping_GM107+0x180a/0x22b0 [nvidia] ? _kbusMapAperture_GM107+0x8b/0xc0 [nvidia] ? _kbusInternalBar1Map+0xe2/0x2a0 [nvidia] ? reusemappingdbMap+0xa8/0x480 [nvidia] ? kbusMapFbAperture_GM107+0x2f5/0x610 [nvidia] ? memMap_IMPL+0x856/0x12e0 [nvidia] ? serverMap+0x30d/0x450 [nvidia] ? rmapiMapToCpuWithSecInfoV2+0x1a6/0x2b0 [nvidia] ? _nv04MapMemory.constprop.0+0x72/0xb0 [nvidia] ? nvkms_call_rm+0x4c/0x90 [nvidia_modeset] ? nvRmApiMapMemory+0x52/0x70 [nvidia_modeset] ? MapMemory+0x42/0x60 [nvidia_modeset] ? __nv_drm_gem_nvkms_map+0x90/0x130 [nvidia_drm] ? __nv_drm_gem_nvkms_mmap+0x1d/0xd0 [nvidia_drm] ? nv_drm_mmap+0xe6/0x190 [nvidia_drm] ? __mmap_region+0x27e/0x980 ? mmap_region+0x91/0xc0 ``` The underlying hardware-level failure is a TLB invalidation timeout (`status=0x65` = `NV_ERR_TIMEOUT`), which then cascades into BAR1 VA-space exhaustion: ``` NVRM: kgmmuInvalidateTlb_GM107: TLB invalidation failed waiting for prior invalidate (status=0x00000065), vaspaceFlags 0x4080081, scope 0x2, GFID 0 NVRM: dmaAllocMapping_GM107: can't alloc VA space for mapping. NVRM: nvAssertOkFailedNoLog: Assertion failed: Generic Error: Invalid state [NV_ERR_INVALID_STATE] (0x00000040) returned from pReuseMappingDb->pMapCb(...) @ mapping_reuse.c:273 NVRM: nvAssertOkFailedNoLog: Assertion failed: Generic Error: Invalid state [NV_ERR_INVALID_STATE] (0x00000040) returned from reusemappingdbMap(&pBar1VaInfo->reuseDb, ...) @ kern_bus_gm107.c:3145 NVRM: mmuWalkUnmap: Failed to unmap VA Range 0x220000 to 0x25ffff. Status = 0x00000040 NVRM: nvAssertFailedNoLog: Assertion failed: (pKernelBus->pReadToFlush != NULL || pKernelBus->virtualBar2[GPU_GFID_PF].pCpuMapping != NULL) @ kern_bus_gv100.c:388 ``` `mmuWalkSparsify` / `mmuWalkUnmap` fail repeatedly over ascending VA ranges (0x1e0000 through 0x29ffff and beyond). The `mapping_reuse.c` / `reusemappingdbMap` / BAR1 path here looks like the same code implicated in NVIDIA/open-gpu-kernel-modules#1134, and the `NV_ERR_INVALID_STATE (0x00000040)` unmap cascade matches #1142. **2. Second gnome-shell thread — state D, blocked on its own process's `mmap_lock`** (held for write by thread 1, above, inside `nv_drm_mmap`). This is why *two* tasks refuse to freeze: ``` task:threaded-ml state:D pid:265896 tgid:7446 rwsem_down_read_slowpath+0x284/0x4d0 down_read_killable+0x48/0xe0 lock_mm_and_find_vma+0xa2/0x240 do_user_addr_fault+0x1c5/0x670 exc_page_fault+0x83/0x1b0 ``` **3. fbcon kworker — holds `console_lock`, blocked on the nvidia_modeset rwsem:** ``` task:kworker/1:3 state:D pid:1177459 Workqueue: events fbcon_register_existing_fbs rwsem_down_read_slowpath+0x284/0x4d0 down_read+0x48/0xd0 nvkms_ioctl_from_kapi+0xdd/0xf0 [nvidia_modeset] GetDynamicDisplayInfo+0x9c/0x190 [nvidia_modeset] ? __nv_drm_connector_detect_internal+0x19b/0x340 [nvidia_drm] ? nv_drm_connector_detect+0xe/0x20 [nvidia_drm] ? drm_helper_probe_detect+0x8e/0xc0 ? drm_helper_probe_single_connector_modes+0x483/0x620 ``` **4. `systemd-sleep`, in the PM *abort* path — blocked forever on `console_lock`:** ``` task:systemd-sleep state:D pid:1177458 ppid:1 console_lock+0x25/0x70 vt_move_to_console+0x18/0xc0 pm_restore_console+0x50/0x60 enter_state+0xb6/0x5f0 pm_suspend+0x44/0xe0 state_store+0x2b/0x60 ``` `setfont` (pid 1177538, from systemd-vconsole-setup) is also permanently blocked on `console_lock`. **Diagnostic gotcha worth recording:** the kernel emitted exactly 10 hung-task warnings (122s, 245s, 368s, 491s) and then went silent at 18:05 — that is `kernel.hung_task_warnings` being exhausted, not recovery. All four tasks stayed in D/R state until the hard reset 14.5 hours later. ## Confirming the reporter's "degraded state" observation I can corroborate the collateral damage described in the original report. From exactly 00:00:00 (logrotate/dpkg-db-backup poking cups) onward, `cups.service` entered an endless start→timeout→stop→timeout→restart loop: **4692 `Killing process ... with signal SIGKILL` lines**, ending in `Processes still around after final SIGKILL. Entering failed mode.` with **67 processes unkillable**. PID 1 also logged: ``` 04:26:47 systemd[1]: Failed to fork off sandboxing environment for executing generators: Protocol error 04:32:48 systemd[1]: Failed to fork off sandboxing environment for executing generators: Protocol error ``` **The operationally worst consequence: this takes SSH down too, so there is no remote recovery.** `ssh.socket` was listening and my incoming connection did arrive and trigger activation, but the service could never start: ``` 08:31:19 systemd[1]: Starting ssh.service - OpenBSD Secure Shell server... 08:32:49 systemd[1]: ssh.service: start-pre operation timed out. Terminating. ``` That is `ExecStartPre=/usr/sbin/sshd -t` failing to complete inside the 90s timeout. (I verified separately that `sshd -t` touches no console/tty devices and normally exits in milliseconds, so it is not blocking on `console_lock` directly — it appears to be the same PID 1 sandbox-fork breakage above.) Consequence: no SSH, no `chvt`, no `systemctl restart display-manager`. A hard reset is the only exit, which on this machine destroys running microk8s workloads. ## Not deterministic Worth noting for anyone trying to reproduce: an earlier idle-suspend the *same day* succeeded cleanly — 12:29:15 suspend, 13:09:49 resume, `Freezing user space processes completed (elapsed 0.005 seconds)`, `PM: suspend exit`, all four displays restored. So this is a race against whatever leaves gnome-shell stuck inside `nv_drm_mmap`, not a guaranteed failure on every suspend. ## Suggestion Independent of the underlying TLB-invalidation timeout, the *deadlock* looks like a missing mitigation rather than a mystery: the "fbcon suspend/resume contends with `console_lock`" class of bug was solved years ago in other DRM drivers by deferring fbcon suspend/resume to a worker when the console lock is already held — nouveau (`drm/nouveau: Handle fbcon suspend/resume in separate worker`) and the generic `drm_fb_helper_set_suspend_lock()` helper, which runs resume asynchronously via a worker if the console lock is already taken. `nvidia-drm`'s fbdev path appears to have no equivalent, so a client wedged inside the driver during a *failed* freeze escalates into an unrecoverable whole-system deadlock. Even without fixing the TLB timeout, making the suspend-abort path unable to deadlock would turn this from "hard reset, lose all running work" into "suspend failed, carry on" — which is what the original reporter asked for. Happy to supply the full `journalctl -b -1 -k` output, `nvidia-bug-report.log`, or test patches / parameter combinations on Turing + 6.8 if that helps move this off Incomplete. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2158993 Title: System hard-freezes after failed suspend (Xwayland freeze timeout) with nvidia-driver-595-open — deadlock in nvidia_modeset/console To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2158993/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
