It seems like the driver version 470 causes a kernel panic upon resuming from suspend, display gets no input signal and keyboard stops responding to input after a few seconds from resuming ( when pressing NumLock, the status lights on the keyboard do not change!) .
I have temporarily downgraded to version 460 until this gets fixed. Logs are attached for both the 470 and 460 ( fully working) versions down below.
A LITTLE BACKGROUND
You may already know that NVIDIA drivers on Linux rely on either of two different methods for power management ( as described here ), which include:
Kernel Driver Callback: Works out of the box with no configuration required, but lacks advanced power management features and preserves only a portion of the video memory.
systemd (/proc/driver/nvidia/suspend): Provides advanced power management features and preserves complete video memory, but requires configuration and setup.
THE CAUSE
Having mentioned the above, upon further inspection I found out the 470 driver migrated to systemd method while previous versions relied on Kernel Driver Callback. Apparently this is broken on some setups and kernels.
THE WORKAROUND
Now it’s obvious we have to revert back to Kernel Driver Callback method for now that the systemd method is broken, and here’s how you can do that:
Reboot and you should be able to suspend and resume properly with driver version 470.xx.
NOTE: Backup your configuration just in case, or downgrade the driver if this does not work on your setup. This was tested on Kubuntu 21.04 with GeForce GT 710.
I face the same issue. My laptop could wake up. However, the primary monitor is very dark, which is equivalent to being unusable at all. Secondary monitory is ok.
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 21.04
Release: 21.04
Codename: hirsute
$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module 470.63.01 Tue Aug 3 20:44:16 UTC 2021
GCC version:
I can think of two possible options that may resolve this issue:
Enabling NVIDIA KMS:
echo options nvidia_drm modeset=1 | sudo tee -a /etc/modprobe.d/nvidia-kms.conf
Generating a new xorg.conf while both displays are plugged in and working through with NVIDIA X Server utility. Maybe fiddle with HardDPMS option in xorg.conf see if anything changes. (More info search for “HardDPMS”)
@humblebee
Please do spin up a new topic, since this one has been tagged as being solved (you solved it :) )
Please repeat any details you feel may be relevant.
I have some more volunteers to help on base Linux issues - so hopefully we can help you faster this time around, but a new topic helps a ton - thanks!
@humblebee What does systemctl start nvidia-<foo>.service mean? Does it put the system into the desired state immediately? All the nvidia service on my Ubuntu 21.04 are in “enabeld” and “inactive (dead)” status, except the nvidia-persistence.service which is “active (running)”. Running `systemctl start nvidia-.suspend.service hangs my system.
Those systemd units are not intended to be started manually, but rather as part of the systemd-suspend.service’s life cycle, which is used to do the low-level work of the systemctl suspend command.
The nvidia-suspend.service unit signals to the NVIDIA driver that it should suspend application access to the GPU, evict the contents of the GPU’s video memory, and get the GPU ready for system suspend. If the system doesn’t actually suspend (e.g. because you started that service manually rather than relying on systemctl suspend to do it for you) then it just wedges anything that tries to access the GPU until you manually start the corresponding nvidia-resume.service.