565.57.01 won't resume from "suspend to RAM"

Snailman, as I’ve said before (probably in another topic about resuming), if I enable any of these services, the OS (Arch, Cinnamon) won’t BOOT at all, let alone wake up from suspend to RAM. If I leave these disabled but enable the DRM parameter, then the desktop becomes unuseable - the icons on the desktop and on the panel become just unclickable pictures with no function, hence I can’t run any program, unless I use Ctrl+ALt+T to run the terminal.

I reported this problem via e-mail and one of the nvidia employees said he had filed the problem with their internal bug report system. So far the only working (for me) combination is 560.35.03 + 6.11.5-rolling. Any versions above those result in no desktop, no boot or not normal resuming. There’s also the not working NVENC but that’s a small issue compared to the rest.

In order to enable the KMS, you need to make sure the nVidia module is loaded in early boot, which probably explains your weird problems. Additionally, a driver update needs to regenerate your RAMFS image (note that this seems to be automatic now on Arch for the nVidia package, in particular with the “open” kernel modules). The MODULES setting above ensures that the driver is loaded earlier in boot, which again, is probably the cause of your system not working when you enable KMS.

Again, I’m not an nVidia employee, just sharing my experience with getting this chip to work over the last couple years. In hindsight, I wish I would have gotten a laptop with an AMD GPU (which, coincidentally also had resume from sleep problems on the iGPU on another laptop, but that was a very minor problem compared to all the problems I’ve had with the RTX3070). The RTX is a fine chip, the AMD linux drivers just worked better for my use cases.

Isn’t this Wayland related issue. In my case it definitely is. I experience no issues when resuming from suspend when using Xorg session. System is Ubuntu 24,04 with the latest Nvidia driver from graphic driver PPA. Btw resuming a Wayland session has never properly worked for me with this or previous Ubuntu version. Tho in most cases the session would at least resume.

Well, I can’t speak for you, but it rings something with a colleague running Ubuntu 24.04 and having issues with nvidia on Wayland. I think he had issues before reaching sleep/resume state, but I do not remember the details, sorry.

I think that Ubuntu packages are notably older than Arch’s (currently running nvidia-lts 565.77 and linux-lts 6.6.70). Also, as I said, I use the iGPU as primary GPU, and the nvidia gpu for gaming/rendering only.

These differences make any comparison very hazardous and prone to error. Even some people on Arch ran into issues apparently with kernel/driver combination that I never witnessed like an ridiculous amount of RAM consumed apparently.

In my case, I am pretty sure the issue was unrelated to Wayland. I had been running for almost 2 years with Wayland and suspend/resume always worked without any problem. Even my display manager, SDDM, is running on Wayland, so there is no X session opened unless I run a program with xwayland for compatibility purposes… which barely happen… I spent some time to dig into the issue and I am pretty sure I had not overlooked anything else when testing the kernel and driver packages at that time.

I am using X11, not Wayland, and I experienced the issue a ton. I will say that I haven’t had a fail to resume in a couple of weeks now (the only thing I changed was updated some packages, none of which were the nVidia drivers, and I enabled nvidia-powerd.service, which isn’t in the documentation for the current release but is nevertheless one of the available services…supposedly just enables boost clocks…).

Btw, today I discovered a new problem with resuming from suspend but I have no idea what could be causing it. However, I’m gonna mention it anyway - just so everyone here’s aware of its existence.

I hadn’t run qbittorrent for quite some time but today I had to. However, I had to go out, so I set it to put the system to sleep when the task is completed, which QBitt did. So far so good. But after that whatever I pressed on the keyboard or on the mouse, the system wouldn’t budge and bother to wake up. The only way was to force a shutdown by flipping the switch on the back of the PSU and then wait for the pre-set reboot (a motherboard power loss setting). I tested it a few times just to be sure and now I’m fairly certain this has something to do with the way QBitt puts the system to sleep and once it enters sleep state, it won’t wake up at all.

I also discovered something else in /etc/systemd/sleep.conf. I’ll do some more experimenting and write here what I have found and whether or not the resuming problem is connected to the config in that file, as I suspect.

Sadly, I had a failure to resume normally today :\ It’s easier to reboot than to restart the DE, as you lose all your running applications anyway.

can confirm i just cannot wake from sleep correctly either. hopefully 570 will have some fixes.

Snailman, faz, as I said earlier, I discovered some things about /etc/systemd/sleep.conf. IDK how it is in other distros but in Arch you could try make its contents like this:

[Sleep]
AllowSuspend=yes
AllowHibernation=no
AllowSuspendThenHibernate=no
AllowHybridSleep=no
#SuspendState=mem standby freeze
#HibernateMode=platform shutdown
#HibernateDelaySec=
#SuspendEstimationSec=60min

and see whether this fixes the resuming problem. On my end it’s partially fixed - sometimes it resumes normally and quite fast, other times it won’t resume at all, third times it will resume after a few seconds have passed with black screen and cursor in the middle of the screen and then suddenly - bam, you have a desktop.
These… sporadic occurrences happened with all drivers I could find whose versions were 565 and above.
However, the resuming problem when qbittorrent is used to put the computer to sleep occured with 560.35.03 and 6.11.5 kernel.

So, after all these troubles, I reverted back to the golden combination: 555.58 + 6.6.35-LTS. Note that the driver version is 555.58, not 555.58.01!!! I have backed up the system with t his combination of kernel and NV driver and burned the backup on a BD-R for the future generations cuz I have the bad feeling we’re not gonna see a better driver with fixed problems anytime soon.

I have not read all comments.
But no one mentioned options needed for suspend to work.

/etc/modprobe.d/nvidia.conf

blacklist nouveau
options nvidia_drm modeset=1
options nvidia_drm fbdev=1
options nvidia NVreg_EnableGpuFirmware=0
options nvidia NVreg_PreserveVideoMemoryAllocations=1 NVreg_TemporaryFilePath=/var/tmp

boot kernel options

nvidia_drm.modeset=1 nvidia_drm.fbdev=1

This needed on 565 current latest driver if you install it from run package.
Some distro have different locations for files and they may put these options if you install from distro-package.

With these changes - suspend works for me on Nvidia.

Information from

https://bbs.archlinux.org/viewtopic.php?pid=2044189#p2044189

Much of what you put in here is conflicted and/or irrelevant, although that last bbs link has some interesting info.

nouveau is already blacklisted by the nVidia driver (at least, on Arch Linux, via the ‘nvidia-utils’ package).

The nvidia_drm options should be set as kernel params; setting them here is redundant. The newest [beta] nVidia driver enables fbdev also by default (although some people are having problems with it). I wouldn’t advise changing such settings without knowing what they do.

NVreg_EnableGpuFirmware may or may not be applicable, depending on if you’re using the closed or open kernel driver. Again, I would caution against such settings without knowing what they do for your particular setup. In the open driver, GSP firmware cannot be disabled, so this setting is ignored.

The last couple lines may conflict with other power management settings. I suggest you read Chapter 21. Configuring Power Management Support

You must have the nvidia systemd services enabled in order for them to work correctly. This should be done automatically, but in my case I found it was not.

I meant Nvidia specific Wayland issue (Technically it could be Nvidia issue, but it doesn’t manifest on Xorg AFAIK). You said it yourself you use you iGPU (Intel or Amd) to render you DE etc.