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
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).
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?
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 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.
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.
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.
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.
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
Well, you can vent your frustration @ people all you want, but:
I don’t work for nVidia, and I have had my share of frustrations with this RTX3070 in my laptop, trust me
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”.
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.
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.
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
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.