**Still reproduces on 595.91.07** — follow-up to my comment #5.
Sixth occurrence on this machine, 2026-09-18, on `nvidia-
driver-595-open` **595.91.07-0ubuntu0.24.04.1** (upgraded from 595.84 on
2026-09-16). Same Turing box as comment #5: GTX 1660 SUPER (TU116,
10de:21c4), Ubuntu 24.04, kernel 6.8.0-139-generic, GNOME Wayland, 4
displays. So the 595.84 -> 595.91.07 bump does not fix it either.
Same signature, abbreviated:
```
16:15:14 systemd-logind[2256]: The system will suspend now!
16:15:15 systemd[1]: Finished nvidia-suspend.service - NVIDIA system suspend
actions.
16:15:16 kernel: NVRM: mmuWalkUnmap: Failed to unmap VA Range 0x1e0000 to
0x21ffff. Status = 0x00000040
16:15:16 kernel: NVRM: nvAssertFailedNoLog: Assertion failed:
(pKernelBus->pReadToFlush != NULL ||
pKernelBus->virtualBar2[GPU_GFID_PF].pCpuMapping != NULL)
@ kern_bus_gv100.c:388
16:15:16 kernel: PM: suspend entry (deep)
16:15:37 kernel: Freezing user space processes
16:15:37 kernel: NVRM: kgmmuInvalidateTlb_GM107: TLB invalidation failed
waiting for prior
invalidate (status=0x00000065), vaspaceFlags 0x4080081, scope
0x2, GFID 0
16:15:37 kernel: NVRM: dmaAllocMapping_GM107: can't alloc VA space for mapping.
16:15:37 kernel: NVRM: nvAssertOkFailedNoLog: ... NV_ERR_INVALID_STATE
(0x00000040) returned from
pReuseMappingDb->pMapCb(...) @ mapping_reuse.c:273
16:18:31 kernel: INFO: task kworker/16:2:2642504 blocked for more than 122
seconds.
Workqueue: events fbcon_register_existing_fbs
16:18:31 kernel: INFO: task systemd-sleep:2659508 blocked for more than 122
seconds.
pm_suspend+0x44/0xe0 / pm_restore_console+0x50/0x60
vt_move_to_console+0x18/0xc0 / console_lock+0x25/0x70
16:18:31 kernel: INFO: task setfont:2659774 blocked for more than 122 seconds.
16:24:39 kernel: Future hung task reports are suppressed, see sysctl
kernel.hung_task_warnings
```
As before this was an **idle-triggered** suspend (GNOME `sleep-inactive-
ac-type=suspend`, 3600s), ~72 minutes after my last interaction. All six
of my occurrences have followed idle-triggered suspends; my manual test
suspends have succeeded, and I have one confirmed clean idle cycle
(2026-08-24 12:29->13:09) on the same driver and session, so it is
intermittent rather than deterministic.
**One new data point on how far the degradation goes.** In this instance
journald itself stopped writing at 17:41:14, about 86 minutes after the
deadlock closed. My later SSH attempt therefore left no record at all —
not even the `ssh.service: start-pre operation timed out` I captured on
2026-09-11. Worth knowing for anyone trying to collect evidence: if you
find a journal that simply ends mid-stream with no shutdown records,
that is consistent with this bug and not with a clean panic.
**On the `NVreg_UseKernelSuspendNotifiers=1` workaround** (dhabyx,
comment #4; MedO, comment #6): my box is still at the packaged default
and has the shared /proc + VT path fully enabled, which is the
configuration both of you identified as the problem:
```
$ grep -iE 'suspend|notifier|Preserve' /proc/driver/nvidia/params
PreserveVideoMemoryAllocations: 1
UseKernelSuspendNotifiers: 0
$ ls /proc/driver/nvidia/suspend*
/proc/driver/nvidia/suspend /proc/driver/nvidia/suspend_depth
$ systemctl is-enabled nvidia-suspend.service nvidia-resume.service
nvidia-hibernate.service
enabled
enabled
enabled
```
That is two independent reports (KDE Plasma/GTX 1650 Mobile, and RTX
3060) of `=1` avoiding or recovering from this, on two different
desktops. I am switching to `=1` with the packaged /proc suspend units
disabled and will report back from Turing either way. This does look
like it supports dhabyx's request in comment #4 that the Open package
use the kernel-notifier path by default rather than the shared /proc/VT
path.
MedO — your `pm_test=freezer` reproducer is the most useful thing in
this thread, since it turns an intermittent overnight outage into
something testable in seconds. I would like to run it, and `suspend-
memory-guard-v1.patch`, on Turing/6.8 to see whether the fix holds
across GPU generations; please do share the script. I can also test with
`nvidia_drm.fbdev=0`, which should remove the
`fbcon_register_existing_fbs` leg of the deadlock entirely — it defaults
to 1 here.
Finally, on the kernel side: this class of console_lock-vs-driver
deadlock in fbcon suspend/resume was addressed years ago in nouveau and
i915 by deferring the fbcon work to a worker when console_lock is
already held. nvidia-drm's fbdev path appears to lack that mitigation,
which is precisely what supplies the `fbcon_register_existing_fbs` leg
here.
This bug still showed "affects 1 person" despite four reporters in the
comments; I have now marked it as affecting me as well.
Happy to attach the full journal for any of my six occurrences.
--
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
