565.57.01 won't resume from "suspend to RAM"

Graphics / Linux Linux
1

Earlier today a new driver appeared, so I updated it. The version is 565.57.01. Tonight I put the computer to sleeep and left. When I came back, I pressed a key on the keyboard to wake it up and it gave me only a black screen with my custom cursor in the middle. I had to reboot by shutting it down by using the switch button at the back of the PSU and then I decided to test it - after the system booted, I put it to sleep again and then almost immediately pressed a key. It gave me the same black screen. I also noticed another difference between 560.35.03 and 565.57.01 - when I press the key that puts the computer to sleep, the whole system (with 565.57.01 installed) “thinks” for about 5 seconds before entering sleep mode, whereas 560.35.03 does that instantly.

555.58 and 560.35.03 DON’T have this problem, so, naturally, I downgraded to 560.35.03. But still, this resuming bug needs to be fixed at some point.

Distro: Arch Linux
Kernel: 6.11.5
DE: Cinnamon 6.2.0 (if that matters,)
DM: GDM (or that)
Video server: Xorg
GPU: RTX 3060

2 Likes
2

Hi @rado84,

  1. Please attach a NVIDIA bug report generated on the next reboot after the failure (Or) if the console is accessible after a VT switch (Ctrl+Alt+F3, Ctrl+Alt+F4 etc).

  2. Do you have linux-lts kernels installed on your systems. If you do, do you mind testing if you see the same issues on kernel - 6.6.58-1-lts and 565.57.01?

Thank you

3

I didn’t have LTS kernel but I installed it for the purpose of this bug report and then updated to the driver version in question. The latest LTS kernel is 6.6.59 but I don’t think that makes much of a difference, since what I reported happens with the LTS kernel as well.

I don’t see a way to attach the result from nvidia-bug-report.sh to this post, so here’s a link to it:
https://www.mediafire.com/file/g8i6agpnlgie9ij/nvidia-bug-report.log.gz

4

I had this problem with the prior release; I believe it was partly triggered by having enabled some power management settings in a module config file to support depowering the GPU (I have a dual graphics laptop, so no need to waste power when the dGPU is not in use).

In the newer nV drivers, I believe it sees that at least some configuration is provided to use the “new” dynamic power management scheme (which uses systemd), whereas if no config is provided it uses a legacy power management method.

My problem was with this partial config provided, it assumed the new method was being used, but I hadn’t enabled all of the systemd daemons for nV DPM; only some were active. This happened in part because of a prompt during updates from Pacman to enable a specific daemon/service, but that advice is incomplete.

Anyway, try making sure you have all of the nVidia DPM systemd services enabled.

5

snailman, I have no idea how to enable these things. Plus it’s not a laptop, it’s a desktop PC with just one GPU, so I’m not sure if your experience applies to my case.
I just came here to open a new topic to ask a question for some clarifications regarding nvidia options on the linux line in grub because I couldn’t find anything helpful on the internet. I suspect that these same options you’re talking about are the ones that I came here to ask about.

6

Take a look at the driver README, it contains a list of services to enable, and settings you can provide to enable power management (including restoring graphics memory when resuming from sleep).

For Arch Linux with systemd, you can enable a service with:
systemctl enable <service_name>, e.g. “systemctl enable nvidia-persistenced”

There are “services” (which are really ultimately ACPI event triggers, in this case) you must enable so that the nVidia driver can properly handle events like sleep, resume from sleep, hibernate, etc. systemd notifies the driver of these events, and makes sure that processes that depend on this event are blocked until the handler (nVidia driver) performs its required tasks.

7

I don’t get why these things aren’t enabled by default with the driver. As I said before, 560.35.03 and 555.58 didn’t need anything to be enabled and they handled power stuff just perfectly.
Thank you for this information but I’d rather keep an older driver and be able to use my system (and play games) than spending an hour or two to research what I have to enable because someone was too lazy to write a few additional lines of code/settings.
So far ALL the drivers with two groups of digits (555.58, 510.57, etc.) have proven to be the most stable and flawless drivers in linux, so I just might go back to 555.58.

8

Hi,

I confirm the same issue on my computer.

TL;DR I solved it by switching to linux-lts (6.6.59 at the current time).

More details if need be below.

Setup:
Arch, KDE, Wayland

01:00.0 VGA compatible controller: NVIDIA Corporation GA104 [GeForce RTX 3060 Ti] (rev a1)
	Subsystem: NVIDIA Corporation Device 147a
	Kernel driver in use: nvidia
	Kernel modules: nouveau, nvidia_drm, nvidia
0c:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raphael (rev c3)
	Subsystem: ASUSTeK Computer Inc. Device 8877
	Kernel driver in use: amdgpu
	Kernel modules: amdgpu
  • Primary GPU is the iGPU (AMD Ryzen 7 7700X).
  • Using GPU PRIME render offload to use the discrete GPU with some applications only (mostly games).
  • Using early KMS to load drivers to work around several issues with wayland and offload rendering.

I configured that setup with linux 6.0.12 and nvidia 525.60.11 in late 2022.
So far I cannot remember major issues, at least not with suspend/resume (I never tried hibernation due to the hassle to set it up on a fully encrypted drive), up to linux 6.11.5 and nvidia 560.35.03.

This was the last working combination. After that:

  • nvidia 560.35.03 breaks resume after sleep (deep) with linux 6.11.6
  • nvidia 565.57.01 breaks resume after sleep (deep) with linux 6.11.5 and 6.11.6

Can’t test other combination because I lack the relevant packages on my drive.

Symptoms: suspend works fine, resume seems to work fine at first but only shows a blinking cursor for a while. System does not respond to a VT Switch. Needs to perform a REISUB to reboot. Latest logs available after reboot in journal shows:

systemd[1]: nvidia-suspend.service: Deactivated successfully.
systemd[1]: Finished NVIDIA system suspend actions.
systemd[1]: nvidia-suspend.service: Consumed 1.120s CPU time, 5.2M memory peak.
systemd[1]: Starting System Suspend...
systemd-sleep[2078]: User sessions remain unfrozen on explicit request ($SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0).
systemd-sleep[2078]: This is not recommended, and might result in unexpected behavior, particularly
systemd-sleep[2078]: in suspend-then-hibernate operations or setups with encrypted home directories.
systemd-sleep[2078]: Performing sleep operation 'suspend'...
kernel: PM: suspend entry (deep)
kernel: Filesystems sync: 0.009 seconds

Hopes that helps somehow…

9

Well, you can vent your frustration @ people all you want, but:

  1. I don’t work for nVidia, and I have had my share of frustrations with this RTX3070 in my laptop, trust me
  2. Linux is not a single, unified OS. It’s a kernel, with many, MANY pieces of software around it (forming your “distro”), and not every distro uses systemd, some are still using init.d, to handle starting and stopping services. Not every machine is x86 based, and thus doesn’t necessarily even have a BIOS/UEFI, or ACPI. nVidia provides drivers that allow the device to work; your distro generally provides “packaging” to install and configure it, in a way that should work for most systems, but it gets complicated really fast. Very little of it has to do with “laziness”.

No offense, but if you don’t even know how to start and stop system services on your distro, it seems like you have some self-education to do before blasting off at developers for being “lazy”.

10

I have the exact same problem, I’ve read from older posts suggesting enabling some services to fix nvidia sleep issues but that didn’t help at all.

11

“but if you don’t even know how to start and stop system services on your distro”

I know how to do that but ONLY if they’re not gpu driver related. GPU services are Greek to me.

12

This has been an ongoing issue for years. Suspend doesn't work when PreserveVideoMemoryAllocations is enabled · Issue #472 · NVIDIA/open-gpu-kernel-modules · GitHub. It was an issue with the parameter Nvreg_PreserveVideoMemoryAllocations and now people are speculating it’s other issues. I’ve hadn’t gotten this to work with 565.57.01. I couldn’t get this to work with 560. I’m using Zen/Vanilla Archlinux. I know how to enable systemd services.

systemctl list-unit-files | grep -i nvidia ~

nvidia-hibernate.service enabled disabled
nvidia-persistenced.service enabled disabled
nvidia-powerd.service enabled disabled
nvidia-resume.service enabled disabled
nvidia-suspend.service enabled disabled
λ ›
If anyone knows if suspension works with LTS kernel I’ll happily install it. I just need answers.

13

why not just use proprietary over open, suspend has been working for me for a while

14

They don’t work, nvidia-dkms or nvidia-open. What kernel and distro are you using. Nvidia-lts doesn’t work either.

15

Just standard nvidia package from arch, make sure preserve memory allocations is set to 1 and you hve nvidia suspend, resume, and hibernate enabled

16

Does not work. Nvidia-lts doesn’t work. Doesnt work with adding those modules in Nvidia.conf. doesn’t work with nvidia-dkms. I shared my systemctl I have those running does not work. What distro and kernel are you using and I’m happy to screenshare

17

I have already tried these things with the early versions of 560.35.03 where the same thing used to happened - no resuming. With these 3 enabled and memory preserve, first it wouln’t resume from suspend and then it wouldn’t boot and hang at “Reached target graphical interface”. I had to run a special respin of Live Debian to remove entries from grub, so that the system could boot. Which is why I “lived”, so to speak, with 555.58 for nearly 6 months.

18

Which combination of Kernel/Driver works for SOMEONE, please?

This is absolutely ridiculous. We’re on 2025. This issue has been going on forever.

1 Like
19

The only combination that works for me flawlessly so far is this:
• Rolling kernel (Arch) 6.11.5
• nvidia-dkms 560.35.03

FORGET about the LTS kernel 6.6.59 as someone suggests on the internet (or was it here?). 560.35.03 or 565.77 + 6.6.59 LTS = random desktop freezes and the used RAM climbing quickly, like going from 5 GB to 24 GB within seconds.
If you want an LTS kernel that works with the nvidia driver and the resuming problem doesn’t exist, you need 6.6.35-lts + nvidia 555.58.

20

FWIW, sleep isn’t working perfectly for me either since the 565 update (I am on the latest, 565.77, 6.12.8 respectively) on Arch, RTX3070 Max Q laptop, Ryzen 5800h.

As mentioned above (but summarized below):
in /etc/modprobe.d/nvidia-pm.conf:

options nvidia “NVreg_DynamicPowerManagement=0x02”
options nvidia “NVreg_EnableS0ixPowerManagement=1”

I have my laptop setup to boot with the dGPU (I haven’t tested hybrid in a while). I have the following services enabled (by default, they are disabled…):
nvidia-hibernate.service
nvidia-persistenced.service
nvidia-powerd.service
nvidia-resume.service
nvidia-suspend.service

*Note: The nividia-powerd.service isn’t listed in Chapter 21 of the README, but nevertheless it’s installed with the driver (the systemd entry exists, it’s just disabled by default). It looks like this is used to turn on “Dynamic Boost”, e.g. temporary overclocking of the GPU/CPU (in tandem?), perhaps to a combined TDP target. I really wish this stuff was maybe part of the nvidia-settings tool…same with the driver options above…and the modeset option below…

I have this in my /etc/mkinitcpio.conf:

…
MODULES=(amdgpu nvidia nvidia_modeset nvidia_uvm nvidia_drm)
…

I use the following kernel params when booting:

nvidia-drm.modeset=1

Now, for me suspend works, it goes to sleep reliably. Waking from sleep has sporadic behavior at times. I am using Cinnamon desktop, and have it set to “Lock” the screen upon sleep.

I get one of the following scenarios (seemingly at random) when waking:

1a) Often, it just works fine and comes up to the lock screen, prompting me for the password…about 75% of the time.
1b) Sometimes, the same thing happens, but my account is locked out for 10 minutes “3 failed attempts”…somehow wake from sleep intermittently sends gibberish to the Lock screen text field and I have to ALT+F2 to login as a super user on console and unlock my account…this sometimes happens a lot, other times it seems to go away for a while…
2a) Sometimes, wake from sleep comes up to a black screen with just my cursor, or sometimes it shows the lock screen but no login prompt…consoles work, but the desktop environment is hosed. The screen is frozen, and shows me the clock from when I put it to sleep…this happens the remaining 25% of the time.
2b) Sometimes, similar to 3, but if I wait a while (30 seconds?) it recovers; the clock starts to update again, and the login prompt works
2c) In some cases, the screen remains frozen, but I can get audible feedback from typing…e.g. I can enter in my password, and sometimes this results in it going to an unlocked desktop.
3) I’ve seen at least a few occasions where when the display initially comes up, my desktop is shown, unlocked, for a moment before the lock screen activates…implies a race condition with the suspend event, the lock screen being activated, and the machine actually going to sleep. Not sure if this is related to the nVidia driver at all.

It would resume from sleep every time in the 560 and prior drivers. I don’t know why it got worse, but it did.