Skip to main content
Topic: [SOLVED?] NVIDIA driver seems to prevent suspending on laptop (Read 300 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[SOLVED?] NVIDIA driver seems to prevent suspending on laptop

Hello everyone,

I have this issues for 1-2 weeks now, that I am unable to get my laptop to suspend properly. Whenever I try to suspend (closing the lid, letting the laptop sit for a while or "loginctl suspend"), the screen just turns black, but the system keeps running. In the case of manually running "loginctl suspend", it goes to a TTY-screen for a brief moment, and ends up showing the SDDM locked user screen, but it never reaches sleep mode. This is obviously an issue for an portable device, as it drains the battery with zero usage.
I didn't get too far with narrowing down the root of the issue, as I updated alot of packages before I noticed this issue. But my dmesg log seems to give some insight:

Code: [Select]
[  +0,006416] [So,  3. Nov 2024, 19:06:07] ata4.00: Entering standby power mode
[  +0,042058] [So,  3. Nov 2024, 19:06:07] NVRM: GPU 0000:02:00.0: PreserveVideoMemoryAllocations module parameter is set. System Power Management attempted without driver procfs suspend interface. Please refer to the 'Configuring Power Management Support' section in the driver README.
[  +0,000697] [So,  3. Nov 2024, 19:06:07] e1000e: EEE TX LPI TIMER: 00000011
[  -0,000680] [So,  3. Nov 2024, 19:06:07] nvidia 0000:02:00.0: PM: pci_pm_suspend(): nv_pmops_suspend [nvidia] returns -5
[  +0,001378] [So,  3. Nov 2024, 19:06:07] nvidia 0000:02:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -5
[  +0,000016] [So,  3. Nov 2024, 19:06:07] nvidia 0000:02:00.0: PM: failed to suspend async: error -5
[  +0,361063] [So,  3. Nov 2024, 19:06:08] PM: Some devices failed to suspend, or early wake event detected
[  +0,021603] [So,  3. Nov 2024, 19:06:08] nvme nvme0: 7/0/0 default/read/poll queues
[  +0,277904] [So,  3. Nov 2024, 19:06:08] usb 1-3.4: reset high-speed USB device number 8 using xhci_hcd
[  +0,022905] [So,  3. Nov 2024, 19:06:08] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[  +0,003589] [So,  3. Nov 2024, 19:06:08] ata4.00: ACPI cmd f5/00:00:00:00:00:a0(SECURITY FREEZE LOCK) filtered out
[  +0,000014] [So,  3. Nov 2024, 19:06:08] ata4.00: ACPI cmd ef/10:03:00:00:00:a0(SET FEATURES) filtered out
[  +0,001159] [So,  3. Nov 2024, 19:06:08] sd 3:0:0:0: [sda] Starting disk
[  +0,000853] [So,  3. Nov 2024, 19:06:08] ata4.00: ACPI cmd f5/00:00:00:00:00:a0(SECURITY FREEZE LOCK) filtered out
[  +0,000012] [So,  3. Nov 2024, 19:06:08] ata4.00: ACPI cmd ef/10:03:00:00:00:a0(SET FEATURES) filtered out
[  +0,000843] [So,  3. Nov 2024, 19:06:08] ata4.00: configured for UDMA/133
[  +0,377068] [So,  3. Nov 2024, 19:06:08] usb 1-3.4.1: reset full-speed USB device number 9 using xhci_hcd
[  +0,038496] [So,  3. Nov 2024, 19:06:08] psmouse serio1: synaptics: queried max coordinates: x [..5676], y [..4758]
[  +0,032667] [So,  3. Nov 2024, 19:06:08] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1096..]
[  +0,124222] [So,  3. Nov 2024, 19:06:09] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_ops [i915])
[  +0,000996] [So,  3. Nov 2024, 19:06:09] OOM killer enabled.
[  +0,000005] [So,  3. Nov 2024, 19:06:09] Restarting tasks ... done.
[  +0,006767] [So,  3. Nov 2024, 19:06:09] random: crng reseeded on system resumption
[  +0,038946] [So,  3. Nov 2024, 19:06:09] PM: suspend exit
[  +0,000080] [So,  3. Nov 2024, 19:06:09] e-suspend[2295]: Failed to put system to sleep. System resumed again: Input/output error
[  +0,004617] [So,  3. Nov 2024, 19:06:09] (sd-exec-[2373]: /usr/lib/elogind/system-sleep/50-intel-undervolt failed with exit status 1, ignoring.
[  +0,003389] [So,  3. Nov 2024, 19:06:09] e-suspend[2295]: e-suspend: shutdown_or_sleep failed: Input/output error


I am running a ThinkPad T470p with hybrid graphics (Intel HD630, NVIDIA Geforce 940MX), with the default "linux" kernel, runit as my init system and Plasma+SDDM as my DE/WM. Currently I have these packages related to nvidia installed:
Code: [Select]
nvidia 565.57.01-1.2
nvidia-prime 1.0-5
nvidia-utils 565.57.01-1
opencl-nvidia 565.57.01-1

As mentioned I am not sure, whether it really is an issue of the nvidia driver itself, or the Linux kernel, or KDE Plasma or Wayland or whatever. The Arch Linux wiki mentions some systemd-service files (that obviously are not bundled in Artix) that should be activated, but I don't think they are the problem, as the system supended fine few updates ago.

Thanks in advance,
nikolas777


Re: NVIDIA driver seems to prevent suspending on laptop

Reply #1
Little update: After removing nvidia and nvidia-utils with pacman -Rcs and rebooting, I was able to put my laptop to sleep again.

So I'm now 100% sure, that it is an issue with the nvidia driver. 2 questions still remain though:
- What did the update do to break suspending?
- How am I able to solve it?

Re: NVIDIA driver seems to prevent suspending on laptop

Reply #2
Ok so it seems that my problem has been solved. Apparently the PreserveVideoMemoryAllocations is set to 1 by default (which I guess wasn't the case before the updates).
Forcing it to be 0 by creating /etc/modprobe.d/nvidia.conf with the following content
Code: [Select]
options nvidia NVreg_PreserveVideoMemoryAllocations=0
and rebooting after that seemed to do the trick.
That is especially weird to me, since I already tried that option almost at first, and it didn't work for some reason, though I'm glad that it works for now.

 

Re: [SOLVED?] NVIDIA driver seems to prevent suspending on laptop

Reply #3
I also have this issue. Sadly setting NVreg_PreserveVideoMemoryAllocations=0 breaks wayland, so I cannot use it to fix this problem.
I think there is a more underlying issue here. As far as I can tell, there seems to have been an update to the nvidia driver, requiring some services to be running to get into sleep successfully without messing with the options. On Arch they are implemented as systemd units, but I don't think they have been ported to Artix.
This related post is kind of describing this, and I think the timeframe is also right since I have been experiencing this for quite some time now: https://forum.artixlinux.org/index.php/topic,7394.msg44528.html