Impossible to resume from suspend with Nvidia GT 710

[Cineris]

Hello,

I have recently changed my graphic card on my desktop : the fan of the older one didn't work anymore and it overheated. I have installed a Nvidia GK208B GeForce GT710.

Since then, I am unable to resume from suspend : the suspend function itself works fine, but when I press a key to resume, I hear the fans turning on, but the screen stays black and I am unable to do anything. I need to reboot by pressing the power button. No other problem with the new video card except this one.

What I have already tried, sadly without any result :

- using different nvidia drivers : nvidia-driver-390, the 450, then 460 (the most recent).
- using the 'nouveau' driver
- using nvidia driver and blacklisting 'nouveau'
- using with LM 20.1 instead of my LM 20
- switching to the non-graphic mode (Ctrl+Alt+F1) before suspending

I have never encountered problems with suspend before changing my video card so I guess the problem comes from here.

Any help would be appreciated !

Here are my computer details :

Code: Select all

System:
  Kernel: 5.4.0-70-generic x86_64 bits: 64 compiler: gcc v: 9.3.0 
  Desktop: Cinnamon 4.6.7 info: plank wm: muffin 4.6.3 dm: LightDM 1.30.0 
  Distro: Linux Mint 20 Ulyana base: Ubuntu 20.04 focal 
Machine:
  Type: Desktop System: HP-Pavilion product: WE184AA-ABF HPE-110fr v: N/A 
  serial: <filter> Chassis: Hewlett-Packard type: 3 serial: <filter> 
  Mobo: MSI model: IONA v: 1.0 serial: <filter> BIOS: American Megatrends 
  v: 5.13 date: 03/03/2010 
CPU:
  Topology: Dual Core model: Intel Core i5 650 bits: 64 type: MT MCP 
  arch: Nehalem rev: 2 L2 cache: 4096 KiB 
  flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 25535 
  Speed: 1741 MHz min/max: 1200/3201 MHz boost: enabled Core speeds (MHz): 
  1: 1381 2: 1317 3: 1359 4: 1226 
Graphics:
  Device-1: NVIDIA GK208B [GeForce GT 710] vendor: Micro-Star MSI 
  driver: nvidia v: 460.39 bus ID: 01:00.0 chip ID: 10de:128b 
  Display: x11 server: X.Org 1.20.9 driver: nvidia 
  unloaded: fbdev,modesetting,nouveau,vesa resolution: 1920x1080~60Hz 
  OpenGL: renderer: GeForce GT 710/PCIe/SSE2 v: 4.6.0 NVIDIA 460.39 
  direct render: Yes 
Audio:
  Device-1: Intel 5 Series/3400 Series High Definition Audio 
  vendor: Hewlett-Packard driver: snd_hda_intel v: kernel bus ID: 00:1b.0 
  chip ID: 8086:3b56 
  Device-2: NVIDIA GK208 HDMI/DP Audio vendor: Micro-Star MSI 
  driver: snd_hda_intel v: kernel bus ID: 01:00.1 chip ID: 10de:0e0f 
  Sound Server: ALSA v: k5.4.0-70-generic 
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
  vendor: Hewlett-Packard driver: r8168 v: 8.048.00-NAPI port: d800 
  bus ID: 02:00.0 chip ID: 10ec:8168 
  IF: enp2s0 state: up speed: 100 Mbps duplex: full mac: <filter> 
  Device-2: Ralink RT2790 Wireless 802.11n 1T/2R PCIe vendor: Lite-On 
  driver: rt2800pci v: 2.3.0 port: e800 bus ID: 04:00.0 chip ID: 1814:0781 
  IF: wlp4s0 state: down mac: <filter> 
  IF-ID-1: ipv6leakintrf0 state: unknown speed: N/A duplex: N/A 
  mac: <filter> 
  IF-ID-2: proton0 state: unknown speed: 10 Mbps duplex: full mac: N/A 
Drives:
  Local Storage: total: 931.51 GiB used: 246.00 GiB (26.4%) 
  ID-1: /dev/sda vendor: Hitachi model: HDS721010CLA332 size: 931.51 GiB 
  speed: 3.0 Gb/s rotation: 7200 rpm serial: <filter> rev: A3BF scheme: MBR 
RAID:
  Hardware-1: Intel SATA Controller [RAID mode] driver: ahci v: 3.0 
  port: b400 bus ID: 00:1f.2 chip ID: 8086.2822 rev: 06 
Partition:
  ID-1: / size: 45.58 GiB used: 23.85 GiB (52.3%) fs: ext4 dev: /dev/sda5 
  ID-2: /home size: 332.02 GiB used: 222.13 GiB (66.9%) fs: ext4 
  dev: /dev/sda7 
  ID-3: swap-1 size: 5.72 GiB used: 30.7 MiB (0.5%) fs: swap dev: /dev/sda6 
Sensors:
  System Temperatures: cpu: 33.0 C mobo: N/A gpu: nvidia temp: 55 C 
  Fan Speeds (RPM): N/A gpu: nvidia fan: 50% 
Repos:
  No active apt repos in: /etc/apt/sources.list 
  Active apt repos in: /etc/apt/sources.list.d/additional-repositories.list 
  1: deb https://repo.protonvpn.com/debian unstable main
  Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list 
  1: deb http://ftp-stud.hs-esslingen.de/pub/Mirrors/packages.linuxmint.com ulyana main upstream import backport
  2: deb http://ubuntu.univ-reims.fr/ubuntu focal main restricted universe multiverse
  3: deb http://ubuntu.univ-reims.fr/ubuntu focal-updates main restricted universe multiverse
  4: deb http://ubuntu.univ-reims.fr/ubuntu focal-backports main restricted universe multiverse
  5: deb http://security.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse
  6: deb http://archive.canonical.com/ubuntu/ focal partner
Info:
  Processes: 239 Uptime: 36m Memory: 5.73 GiB used: 1.79 GiB (31.3%) 
  Init: systemd v: 245 runlevel: 5 Compilers: gcc: 9.3.0 alt: 9 Shell: bash 
  v: 5.0.17 running in: gnome-terminal inxi: 3.0.38 

[SMG]

Since then, I am unable to resume from suspend : the suspend function itself works fine, but when I press a key to resume, I hear the fans turning on, but the screen stays black and I am unable to do anything.

Try restarting X Server with Ctl-Alt-Backspace. That might work if the issue is somehow the port is not waking and thus the screen is not getting input. Restarting X server should re-poll the graphics ports.

Along those lines, remove both ends of your video cable and re-attach them securely just to rule out a slight misalignment in the connection.

I need to reboot by pressing the power button.

The next time that happens, run the following:
journalctl -rb -1 | nc termbin.com 9999
It prints the journal log information of the prior boot cycle (the one which ended in a black screen) in reverse order (so hopefully the problem is near the top) and sends it to termbin. It will return with a url address that you should post in your next reply.

I have never encountered problems with suspend before changing my video card so I guess the problem comes from here.

Did you do any kernel updates or any other updates in between when you had the older card installed and when you put the new one in place? I'm wondering if the system is not properly going into full sleep mode and thus that is why it does not resume properly.

[Cineris]

Thank you for your answer and for helping me.

Try restarting X Server with Ctl-Alt-Backspace. That might work if the issue is somehow the port is not waking and thus the screen is not getting input.

I tried and it didn't work. When the screen stays black after trying to resume, it seems the system is completely frozen : it doesn't reply to Ctl-Alt-Backspace nor to any other shortcut ; I already tried to reboot with Alt-Sys-b, with no success.

Along those lines, remove both ends of your video cable and re-attach them securely just to rule out a slight misalignment in the connection.

Done. The problem stays the same.

The next time that happens, run the following:
journalctl -rb -1 | nc termbin.com 9999
It will return with a url address that you should post in your next reply.

Here is the address : https://termbin.com/6khf

Did you do any kernel updates or any other updates in between when you had the older card installed and when you put the new one in place? I'm wondering if the system is not properly going into full sleep mode and thus that is why it does not resume properly.

My video card was changed on January the 26th. I've done a kernel update on Jan. 21st : upgrading from 5.4.0.59 to 5.4.0.64. But I didn't notice a problem with suspend between 21st and 26th, although I use it almost every day. There are several other updates (xserver, systemd,...), but I can't copy/paste them from the updates history in Mint. Is there a command to get the history in the terminal or a log file I could copy/paste ? Sorry, this is probably very basic, but I'm pretty new to LM.

[Tomcat_]

Try adding acpi_osi=! acpi_osi=\"Windows 2009\" to the kernel cmdline (/etc/default/grub). Worked for me (see first reply in viewtopic.php?f=59&t=347084&sid=7c8f1e5 ... 4096559a5f)

[Cineris]

Try adding acpi_osi=! acpi_osi=\"Windows 2009\" to the kernel cmdline (/etc/default/grub). Worked for me (see first reply in viewtopic.php?f=59&t=347084&sid=7c8f1e5 ... 4096559a5f)

Thanks for the tip.
I have added GRUB_CMDLINE_LINUX="acpi_osi=! acpi_osi=\"Windows 2009\""
in my /etc/default/grub. Then I launched "sudo update-grub", rebooted and tried to suspend.
It didn't work : I am still unable to resume from suspend

[SMG]

Thanks for the tip.
I have added GRUB_CMDLINE_LINUX="acpi_osi=! acpi_osi=\"Windows 2009\""
in my /etc/default/grub. Then I launched "sudo update-grub", rebooted and tried to suspend.
It didn't work : I am still unable to resume from suspend

Please remove that so it does not cause other problems. You have an HP desktop and not a dual-graphics laptop like the person who posted that, so your hardware is quite different. There are downsides to all kernel parameters and one should understand what they are before adding kernel parameters.

I am going through the log now to see if I can determine what the problem might be. The system is not responding at all to your attempts to wake it so I am going back through the entire log to see if I can find any hints of what the problem might be. I will let you know what I find.

[SMG]

I have recently changed my graphic card on my desktop : the fan of the older one didn't work anymore and it overheated. I have installed a Nvidia GK208B GeForce GT710.

What was the prior card?
Did the overheating seem like it may have done damage to anything more than just the graphic card?

Since then, I am unable to resume from suspend : the suspend function itself works fine, but when I press a key to resume, I hear the fans turning on, but the screen stays black and I am unable to do anything. I need to reboot by pressing the power button. No other problem with the new video card except this one.

In other cases where the graphics driver or the graphics card were a problem, the rest of the computer would resume from suspend and there would be errors related to the graphics driver or the connection to the actual graphics card.

In this case, the computer is not responding at all. You have indicated the fans turn on, but nothing in the operating system is activated. These are the last few lines from the log. The computer suspends and goes to sleep and the operating system never gets a signal to wake up.

Code: Select all

avril 15 10:37:58 consul systemd[1]: Reached target Sleep.
avril 15 10:37:58 consul systemd[1]: Starting Suspend...
avril 15 10:37:58 consul systemd-sleep[7465]: Suspending system..
avril 15 10:37:58 consul kernel: PM: suspend entry (deep)

According to this Does this line in a log mean that I have a bad RAM sector or chip?, the below could be corrupted physical memory, corrupted BIOS, or wrong MTRR size. If you have not done any recent changes to memory, it may be the last item and may just be the fact the memory is newer than the motherboard. The last person who had these types of messages was having problems with system freezes. I do not recall if that person was putting their computer to sleep.

Code: Select all

avril 15 09:36:38 consul kernel: *BAD*gran_size: 64K         chunk_size: 2G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 64K         chunk_size: 1G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 128K         chunk_size: 2G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 128K         chunk_size: 1G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 256K         chunk_size: 2G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 256K         chunk_size: 1G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 512K         chunk_size: 2G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 512K         chunk_size: 1G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 1M         chunk_size: 2G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 1M         chunk_size: 1G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 2M         chunk_size: 2G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 2M         chunk_size: 1G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 4M         chunk_size: 2G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 4M         chunk_size: 1G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 8M         chunk_size: 2G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 8M         chunk_size: 1G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 16M         chunk_size: 2G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 16M         chunk_size: 1G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 32M         chunk_size: 2G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 32M         chunk_size: 1G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 64M         chunk_size: 2G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 64M         chunk_size: 1G         num_reg: 8          lose cover RAM: -512M
avril 15 09:36:38 consul kernel: *BAD*gran_size: 128M         chunk_size: 512M         num_reg: 8          lose cover RAM: -0G
avril 15 09:36:38 consul kernel: mtrr_cleanup: can not find optimal value
avril 15 09:36:38 consul kernel: please specify mtrr_gran_size/mtrr_chunk_size

The following is your /home. The system is doing fsck on it and did some fixes when starting up. I do not know if those files were orphaned when the computer was powered off during suspend or if something else happened.

Code: Select all

avril 15 09:36:51 consul systemd-fsck[650]: /dev/sda7: Lors de l'effacement de l'i-noeud orphelin 2911107 (uid=1000, gid=1000, mode=0100664, taille=74126)
avril 15 09:36:51 consul systemd-fsck[650]: /dev/sda7: Lors de l'effacement de l'i-noeud orphelin 2920496 (uid=1000, gid=1000, mode=0100664, taille=74126)
avril 15 09:36:51 consul systemd-fsck[650]: /dev/sda7: Lors de l'effacement de l'i-noeud orphelin 2895985 (uid=1000, gid=1000, mode=0100600, taille=147052)
avril 15 09:36:51 consul systemd-fsck[650]: /dev/sda7: Lors de l'effacement de l'i-noeud orphelin 2896055 (uid=1000, gid=1000, mode=0100664, taille=32768)
avril 15 09:36:51 consul systemd-fsck[650]: /dev/sda7: Lors de l'effacement de l'i-noeud orphelin 2921431 (uid=1000, gid=1000, mode=0100664, taille=74126)
avril 15 09:36:51 consul systemd-fsck[650]: /dev/sda7: Lors de l'effacement de l'i-noeud orphelin 2905097 (uid=1000, gid=1000, mode=0100664, taille=74126)
avril 15 09:36:51 consul systemd-fsck[650]: /dev/sda7: Lors de l'effacement de l'i-noeud orphelin 2884207 (uid=1000, gid=1000, mode=0100600, taille=109764)
avril 15 09:36:51 consul systemd-fsck[650]: /dev/sda7: Lors de l'effacement de l'i-noeud orphelin 2884400 (uid=1000, gid=1000, mode=0100664, taille=32768)
avril 15 09:36:51 consul systemd-fsck[650]: /dev/sda7: Lors de l'effacement de l'i-noeud orphelin 2912404 (uid=1000, gid=1000, mode=0100664, taille=74126)
avril 15 09:36:51 consul systemd-fsck[650]: /dev/sda7: Lors de l'effacement de l'i-noeud orphelin 2897220 (uid=1000, gid=1000, mode=0100664, taille=74126)
avril 15 09:36:51 consul systemd-fsck[650]: /dev/sda7 : propre, 2324644/22175744 fichiers, 59898599/88691200 blocs

At this point, I am leaning toward this being a possible hardware issue rather than a software issue. Have you changed anything other than the graphics card recently?

[Cineris]

I have removed the GRUB_CMDLINE_LINUX="acpi_osi=! acpi_osi=\"Windows 2009\""
I wanted to give it a try since I had already read other posts concerning fixes with ACPI (see, for example : http://iam.tj/prototype/enhancements/Wi ... i_osi.html). But it doesn't work, anyway.

What was the prior card?

It was a Nvidia GeForce GT 230.

Did the overheating seem like it may have done damage to anything more than just the graphic card?

I don't think so : I have not noticed any other problem on the computer and I changed the graphic card 2 or 3 days after noticing the overheating.

In other cases where the graphics driver or the graphics card were a problem, the rest of the computer would resume from suspend and there would be errors related to the graphics driver or the connection to the actual graphics card.

I understand. I thought the graphic card was the source of the problem since this problem occurred just after changing the card. But it could be a coincidence.

According to this Does this line in a log mean that I have a bad RAM sector or chip?, the below could be corrupted physical memory, corrupted BIOS, or wrong MTRR size. If you have not done any recent changes to memory, it may be the last item and may just be the fact the memory is newer than the motherboard.

I haven't done any change to the memory ; no new material was installed except the video card. In a URL related to the one you refer to (https://web.archive.org/web/20190904223 ... blems.html), the author recommends using MTRR_SANITIZER if the kernel message contains those lines (which is my case) :

Code: Select all

mtrr: no more MTRRs available
[drm] MTRR allocation failed.  Graphics performance may suffer.

Would it be useful for me to follow the author's advice ? I don't understand all the steps...

The following is your /home. The system is doing fsck on it and did some fixes when starting up. I do not know if those files were orphaned when the computer was powered off during suspend or if something else happened.

No idea. That's beyond my knowledge...

At this point, I am leaning toward this being a possible hardware issue rather than a software issue. Have you changed anything other than the graphics card recently?

I haven't changed anything except the video card. But my computer is pretty old (11 years) and an other hardware failure is not unlikely. Although I'm still puzzled by the coincidence between the suspend problem and the installation of the new video card.

Another piece of information I forgot to mention : I have a dual boot with Win7. After changing my video card, I can no longer use the suspend function in Windows : the function is not available at all. With the previous video card, it was and worked flawlessly. I don't know if it's related to my issue with LM.

[SMG]

Another piece of information I forgot to mention : I have a dual boot with Win7. After changing my video card, I can no longer use the suspend function in Windows : the function is not available at all. With the previous video card, it was and worked flawlessly. I don't know if it's related to my issue with LM.

Yes, it probably is. This seems to indicate the issue is hardware-related since it is happening on two unrelated operating systems. Since the only thing you changed was the graphics cards, then the issue seems to be related to the physical card.

I looked up the specs for the two cards. Your original card had a higher power requirement than the newer one, so I would not think your current PSU (power supply unit) should be a factor.

If you have not yet tried removing and reinstalling the card (just to make sure everything is seated and connected properly), I suggest doing that. Also check the BIOS. Maybe there is a setting related to power options or sleep options which might impact the card? I have not done much troubleshooting of graphics cards, so I do not know what might relate to this type of issue.

I haven't done any change to the memory ; no new material was installed except the video card. In a URL related to the one you refer to (https://web.archive.org/web/20190904223 ... blems.html), the author recommends using MTRR_SANITIZER if the kernel message contains those lines (which is my case) :

Code: Select all

mtrr: no more MTRRs available
[drm] MTRR allocation failed.  Graphics performance may suffer.

Would it be useful for me to follow the author's advice ? I don't understand all the steps...

Given your statement about suspend not working in Win7 and the fact you did not change the memory, I do not think this is related to the issue. Your system probably had these messages before you changed the card and you did not have issues, so this may be something which does not need any attention from you.

The following is your /home. The system is doing fsck on it and did some fixes when starting up. I do not know if those files were orphaned when the computer was powered off during suspend or if something else happened.

No idea. That's beyond my knowledge...

fsck is file system check and is done to check the integrity of the files. Sometimes powering off the system using the power button instead of shutting down in a normal manner can result in files being corrupted. This indicates the system fixed some errors it found.

[Cineris]

If you have not yet tried removing and reinstalling the card (just to make sure everything is seated and connected properly), I suggest doing that.

I have just tried it. It did not solve the problem.

Also check the BIOS. Maybe there is a setting related to power options or sleep options which might impact the card?

I have checked the BIOS but have not found any setting for powering or suspending the computer. The available settings are pretty few, actually, and basic.

fsck is file system check and is done to check the integrity of the files. Sometimes powering off the system using the power button instead of shutting down in a normal manner can result in files being corrupted. This indicates the system fixed some errors it found.

Thanks for the explanation.

Is there a chance that a future update in the linux kernel could fix my problem or should I rather check upcoming updates of the nvidia driver ?

[SMG]

Is there a chance that a future update in the linux kernel could fix my problem or should I rather check upcoming updates of the nvidia driver ?

You are having the same problem on Windows. This is not an issue with Mint or its kernel or drivers. It is an issue related to the computer's hardware.

How are you putting the computer to sleep?

[Cineris]

How are you putting the computer to sleep?

I usually do it through the Mint menu ("Suspend / Reboot / Shut down"). I have tried also with the command :

Code: Select all

systemctl suspend

With both methods, the computer freezes when I try to resume from suspend.

[SMG]

With both methods, the computer freezes when I try to resume from suspend.

The computer is not freezing when you try to resume from suspend. The computer is not responding to your attempts to resume from suspend. You put the computer to sleep and it never wakes up. It stays suspended and then you risk corrupting your Mint install every time you kill the power in that suspended state. In fact, we know corruption is happening because fsck put messages in the log saying it fixed problems.

My advice to you is to stop suspending the computer until you figure out what is wrong with the hardware and get it fixed/replaced.

Maybe someone else will have some other ideas.

[Cineris]

OK.
Thank you for your time and for trying to help me.

[DrM]

I also suffer from this problem, could it be that the Nvidia GT 710 has a buggy APCI implementation?

[roblm]

Anyone having a suspend and resume problem with Nvidia graphics should install the Nvidia-465 or 470 driver series if possible, because these drivers also install the systemd services nvidia-suspend.service and nvidia-resume.service to /lib/systemd/system

Then use the command sudo systemctl suspend to suspend.

Previously if suspend did not work, you had to manually add those services. See the post by viorel in this topic.
viewtopic.php?f=59&t=350741

Additional info:
http://us.download.nvidia.com/XFree86/L ... ement.html

[Cineris]

I was using nvidia-driver-460 and switched to 470, following your advice. Unfortunately, the problem remains : when I try to resume from suspend, the fan of the desktop turns on, but the screen stays black and I can not do anything. I have to reboot using the power button.

The services nvidia.resume and nvidia.suspend are both enabled, I have checked with

Code: Select all

systemctl is-enabled

[roblm]

The article in this link, under the section Preserve all video memory allocations mentions S0ix-based power management:
http://us.download.nvidia.com/XFree86/L ... ement.html

Use this command to check if your Nvidia GPU has support for that method:
grep 'Video Memory Self Refresh' /proc/driver/nvidia/gpus/0000:01:00.0/power

If the result says Supported, then open the grub file: xed admin:///etc/default/grub

Change this line:

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

To this, by adding the kernel parameter NVreg_EnableS0ixPowerManagement=1:

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash NVreg_EnableS0ixPowerManagement=1"

Then update grub: sudo update-grub


Note to other users: the value of 1 in this line may be different on your system.
/proc/driver/nvidia/gpus/0000:01:00.0/power

Use the command inxi -Gx and check this line:
driver: nvidia v: 460.39 bus ID: 01:00.0

[Cineris]

Thanks for your help, roblm.

The command result is Not Supported, so I can't use S0ix Power Management and I didn't change anything in the grub.

I have been through the article you pointed in your previous post, but I am not sure I understood everything in it, since I am pretty new to Linux. I understood there are two ways of handling power management with the nvidia driver : the default mechanism ("Kernel driver callback") and the systemd configuration. On my computer, the systemd (with the service manager) doesn't seem to work. Is it possible to try using the default mechanism with the nvidia 470 driver ? I don't see how to do so. Sorry if this a stupid question, I am a bit confused...

[roblm]

Is it possible to try using the default mechanism with the nvidia 470 driver ?

That Nvidia article can be difficult to understand completely. I’m not even sure I understand all of it.
I think the systemd method is only used when the command sudo systemctl suspend is used. If suspend is initiated using the Quit button in the menu, then the default method is used.

However, to be certain, you can disable the nvidia-suspend.service and nvidia-resume.service with these commands:

Code: Select all

sudo systemctl disable nvidia-suspend.service
sudo systemctl disable nvidia-resume.service

Here is another method to try. Create an xorg.conf file: sudo touch /etc/X11/xorg.conf

Open the file for editing: xed admin:///etc/X11/xorg.conf

Add these lines and then log out and back in:

Code: Select all

Section "Device"
   Identifier   "Device0"
   Driver   "nvidia"   			
   Option "HardDPMS" "true" 
EndSection