Follow-up: I tested three configurations on the affected kernel (7.0.0-31.31).
The results narrow this down a bit, and suggest the deadlock is not
caused by the GPU fault itself but by user sessions being left unfrozen during
suspend.
CONFIG A - as shipped (baseline)
NVreg_PreserveVideoMemoryAllocations=1
SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false (as shipped by
nvidia-kernel-common-610)
Result: intermittent unrecoverable deadlock, ~4 failures in 20 suspends.
This is the originally reported failure.
CONFIG B - disable video memory preservation
NVreg_PreserveVideoMemoryAllocations=0
SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false
Result: deadlock GONE. Suspend and resume complete:
19:27:11 PM: suspend entry (deep)
19:27:48 Freezing user space processes completed (elapsed 0.002 seconds)
19:27:48 PM: suspend exit
But the display pipeline is broken on resume - the session comes back to a
mostly unrendered screen with only the hardware cursor drawn:
nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device
Samsung SMB2230H (DP-3)
gnome-shell: Failed to use stored monitor configuration: Invalid mode
1920x1080 (60.000)
[drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* Flip event timeout on head 0
[drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* Flip event timeout on head 1
[drm:nv_drm_atomic_apply_modeset_config [nvidia_drm]] *ERROR* Failed to
initialize semaphore for plane fence
[drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* Failed to apply atomic
modeset. Error code: -11
Not a usable workaround, but it confirms the video-memory save path is
involved in the deadlock.
CONFIG C - keep video memory preservation, re-enable session freezing
NVreg_PreserveVideoMemoryAllocations=1 (package default, unchanged)
SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=true (via a drop-in in /etc/systemd/system/
systemd-suspend.service.d/ overriding
NVIDIA's
nvidia-suspend-nofreeze.conf)
Result: no deadlock, and resume is completely clean - no drm errors, no
display corruption. Suspend is delayed by ~32s, but it completes:
19:43:04.878 systemd-suspend.service starting
19:43:08.875 NVRM: kgmmuInvalidateTlb_GM107: TLB invalidation failed
waiting for prior invalidate (status=0x00000065)
19:43:12.876 NVRM: kgmmuInvalidateTlb_GM107: TLB invalidation failed ...
19:43:16.877 NVRM: kgmmuInvalidateTlb_GM107: TLB invalidation failed ...
19:43:20.878 NVRM: kgmmuInvalidateTlb_GM107: TLB invalidation failed ...
19:43:24.879 NVRM: kgmmuInvalidateTlb_GM107: TLB invalidation failed ...
19:43:28.880 NVRM: kgmmuInvalidateTlb_GM107: TLB invalidation failed ...
19:43:32.881 NVRM: kgmmuInvalidateTlb_GM107: TLB invalidation failed ...
19:43:36.882 NVRM: kgmmuInvalidateTlb_GM107: TLB invalidation failed ...
19:43:36.889 PM: suspend entry (deep)
19:43:42.522 Freezing user space processes completed (elapsed 0.001
seconds)
19:43:42.535 PM: suspend exit
Exactly 8 TLB invalidate retries at 4s intervals = ~32s of delay, then
suspend proceeds normally.
WHAT THIS SUGGESTS
The GPU TLB invalidation failure is still present in config C - it is not fixed,
just survived. The retries eventually stop and suspend continues.
The difference is what happens while the GPU is in that state. With user
sessions unfrozen (configs A and B, the shipped default), gnome-shell can issue
an nvkms MapMemory during the window, block indefinitely in
kgmmuInvalidateTlb_GM107, and hold the nvidia-modeset rwsem. The fbcon takeover
kworker then blocks on that rwsem while holding console_lock, and
pm_restore_console deadlocks behind it.
With sessions frozen (config C), the compositor cannot issue that request, so
the same GPU fault degrades to a delay instead of an unrecoverable hang.
nvidia-suspend-nofreeze.conf, which sets
SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false,
states in its own comment that it exists to avoid a VT-switch deadlock with
Xorg.
This is a Wayland session, so the workaround provides no benefit here while
creating the window the deadlock needs. Not applying it to Wayland sessions
would
appear to avoid the hang on this system.
I am happy to test patches or other configurations.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2166914
Title:
[regression 7.0.0-30 -> 7.0.0-31] Suspend deadlocks in
pm_restore_console: fbcon takeover holds console_lock while blocked on
nvidia-modeset rwsem
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2166914/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
