Correction and longer-term data on config C. In my previous comment I reported that config C delays suspend by ~32s due to repeated kgmmuInvalidateTlb_GM107 retries. That measurement was taken from a single suspend a few minutes after reboot and is not representative. Steady-state behaviour over a full day is different in both cause and duration, so I want to correct the record.
DATA: 11h43m uptime, 6 suspend/resume cycles, all on 7.0.0-31.31 with config C (NVreg_PreserveVideoMemoryAllocations=1, SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=true) TLB invalidation failures: 0 Kernel "Freezing ... failed": 0 Hung task reports: 0 nvidia-drm errors on resume: 0 Deadlocks: 0 So the originally reported deadlock did not recur, and - importantly - the GPU fault that triggers it did not occur either. No TLB invalidation failures at all across the whole day. THE DELAY IS NOT GPU-RELATED The ~60s delay before suspend is a systemd freeze timeout, not the driver: 17:43:42.270 session-2.scope: Unit now frozen-by-parent. 17:44:42.320 systemd-sleep: Failed to freeze unit 'user.slice': Connection timed out 17:44:42.329 systemd-sleep: Performing sleep operation 'suspend'... Measured delay from "Starting systemd-suspend.service" to "Performing sleep operation", per cycle: 08:13:12.500 -> 08:14:12.587 60.087s freeze timed out 10:12:27.292 -> 10:13:27.382 60.089s freeze timed out 11:32:22.771 -> 11:33:22.853 60.082s freeze timed out 14:04:47.943 -> 14:05:48.021 60.078s freeze timed out 16:15:59.367 -> 16:15:59.403 0.036s freeze SUCCEEDED 17:43:42.248 -> 17:44:42.329 60.081s freeze timed out The difference between the fast cycle and the slow ones is which units actually freeze. On the one fast cycle all three froze: 16:15:59.394 user-1000.slice: Unit now frozen-by-parent. 16:15:59.394 session-2.scope: Unit now frozen-by-parent. 16:15:59.394 [email protected]: Unit now frozen-by-parent. 16:15:59.394 Successfully froze unit 'user.slice'. On the five slow cycles only session-2.scope froze; user-1000.slice and [email protected] did not, and the operation timed out after exactly 60s before suspend proceeded anyway. This may be a separate systemd issue rather than anything to do with this bug, but it is the direct consequence of overriding nvidia-suspend-nofreeze.conf, so it seems worth recording here. CAVEAT ON WHAT THIS PROVES Because the freeze times out in 5 of 6 cycles, the user session is largely NOT frozen when suspend proceeds. Config C is therefore only partially doing what I described in my previous comment. Given that zero TLB invalidation failures occurred in this period, I cannot claim config C prevents the deadlock. The honest reading is that the underlying GPU fault simply did not occur during these 24 hours. With an original failure rate of roughly 1 in 5 suspends, six clean cycles is not sufficient evidence either way. I will report back if the fault recurs, with whichever outcome follows. -- 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
