NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

obap74 · 2024-01-10 21:47:44

bertieb wrote:

obap74 wrote:
I switched to nvidia-535xx-dkms and nvidia-535xx-utils on the AUR for the meantime. 6.1.71-1 and 6.5.9.arch2-1 + NVIDIA 535 still work as expected. I consider switching to 6.1 kernel on the AUR. Again, not a big deal on my end since Arch is my backup distro and I almost never use it.
Ah, good point about AUR versions of drivers and kernel! Is this the normal route for these sorts of situtations?

I've been using Arch for about 7 years and it's the first time I have to do this. I've always used kernels / NVIDIA drivers from official repositories. Hopefully this will be fixed at some point...

bertieb · 2024-01-10 22:18:27

obap74 wrote:

I've been using Arch for about 7 years and it's the first time I have to do this. I've always used kernels / NVIDIA drivers from official repositories. Hopefully this will be fixed at some point...

Me too. Is there a benefit to using AUR packages to stay on a particular version instead of IgnorePkg-ing those packages?

obap74 · 2024-01-11 10:14:22

bertieb wrote:

Me too. Is there a benefit to using AUR packages to stay on a particular version instead of IgnorePkg-ing those packages?

I have mixed feelings about this. Running up-do-date kernels/drivers from the AUR sounds dangerous but so does running outdated kernels/drivers from official Arch repos.

Assuming the maintainers regularly update the packages and you can audit the PKGBUILDs (PKGBUILDs for kernels / drivers are more complex than less critical packages ones), maybe the first option is better. At least you would get the new revisions (6.1 kernel is supported until December 2026 and 535 NVIDIA drivers until June 2026).

Arch ships the latest and greatest, but if you want to avoid that for some very specific packages that cause regressions, then you're on your own. That's one of the reasons why I use Gentoo as my main distro.

Last edited by obap74 (2024-01-11 11:21:09)

bertieb · 2024-01-11 10:35:07

obap74 wrote:

bertieb wrote:
Me too. Is there a benefit to using AUR packages to stay on a particular version instead of IgnorePkg-ing those packages?
I have mixed feelings about this. Running up-do-date kernels/drivers from the AUR sounds dangerous but so does running outdated kernels/drivers from official Arch repos.
Assuming the maintainers regularly update the packages and you can audit the PKGBUILDs (PKGBUILDs for kernels / drivers are more complex than less critical packages ones), maybe the second option is better. At least you would get the new revisions (6.1 kernel is supported until December 2026 and 535 NVIDIA drivers until June 2026).
Arch ships the latest and greatest, but if you want to avoid that for some very specific packages that cause regressions, then you're on your own. That's one of the reasons why I use Gentoo as my main distro.

When you say the second one, do you mean using the AUR packages? It reads that way as you talk about receiving new revisions, but I just wanted to check.

I'm not sure I have the expertise to properly audit a PKGBUILD; I feel I'd probably miss anything except the most blatant, echo 'including rootkit...' type things. Switching distro is another option, but it feels a little extreme!

obap74 · 2024-01-11 11:22:24

bertieb wrote:

When you say the second one, do you mean using the AUR packages? It reads that way as you talk about receiving new revisions, but I just wanted to check.

Yes, sorry. I meant the first option (up-to-date AUR packages rather than outdated packages from Arch repos).

seth · 2024-01-11 14:10:40

Short-term I'd certainly opt for stalling the repo packages (unless a major CVE is announced for the kernel)

Hopefully this will be fixed at some point...

If nvidia can't fix this for a while, you might want to start looking at nvidia-open (though a specific caveat is that S3/4 doesn't work…) or will be forced to switch to the AUR kernel because you run into issues w/ toolchain changes (ie. the old pre-built kernel doesn't boot)

bertieb · 2024-01-11 14:36:30

seth wrote:

Short-term I'd certainly opt for stalling the repo packages (unless a major CVE is announced for the kernel)
Hopefully this will be fixed at some point...
If nvidia can't fix this for a while, you might want to start looking at nvidia-open (though a specific caveat is that S3/4 doesn't work…) or will be forced to switch to the AUR kernel because you run into issues w/ toolchain changes (ie. the old pre-built kernel doesn't boot)

Thanks for the tip about nvidia-open. Is that caveat about S3/4 related to this issue - is that a "not implemented yet" I take it? A comment on another issue from a couple of years ago seems to suggest that it at that point they had not been implemented. There is also this note on the nvidia page:

The following features are not yet supported by the open kernel modules:
- NVIDIA virtual GPU (vGPU)
- G-Sync on notebooks
- Preserving video memory across power management events

It also seems from the compatibility list info that only relatively recent (post-Turing) cards are supported, so those with GTX 970s presumably cannot use nvidia-open.

If a fix is not forthcoming doable it seems the choice would be the same whether nvidia or nvidia-open, between: being stuck on a driver version, or not having suspend.

juneidy · 2024-01-15 00:31:34

Latest test on 6.7 kernel: GTX 970; core/linux 6.7.arch3-1; extra/nvidia 545.29.06-12

Still does not wake from suspend.

obap74 · 2024-01-15 08:35:44

juneidy wrote:

Latest test on 6.7 kernel: GTX 970; core/linux 6.7.arch3-1; extra/nvidia 545.29.06-12
Still does not wake from suspend.

Thanks for the heads up.

obap74 · 2024-01-21 18:04:59

Still working fine with linux-lts 6.1.71-1 and new NVIDIA 535 update from the AUR (nvidia-535xx-dkms 535.154.05-1 ). I suspended/resumed three times in a row.

Cotton · 2024-01-21 20:03:11

obap74 wrote:

Still working fine with linux-lts 6.1.71-1 and new NVIDIA 535 update from the AUR (nvidia-535xx-dkms 535.154.05-1 ). I suspended/resumed three times in a row.

Yes, but more importantly, does 535.154.05 work with 6.7?

Unfortunately for me, the latest 470 driver is still from 2023-10-31 but yours has been updated twice since then and is 2024-01-16.

obap74 · 2024-01-21 20:34:11

Cotton wrote:

obap74 wrote:
Still working fine with linux-lts 6.1.71-1 and new NVIDIA 535 update from the AUR (nvidia-535xx-dkms 535.154.05-1 ). I suspended/resumed three times in a row.
Yes, but more importantly, does 535.154.05 work with 6.7?

I haven't tried but considering I never had success with the following combinations:

6.6.0 + 535.129.03
6.6.1 + 535.129.03
6.6.7 + 535.146.02

I would be surprised.

obap74 · 2024-01-25 14:21:11

NVIDIA 550.40.07 beta driver was released yesterday. No mention of this issue in the changelog, we'll see.

obap74 · 2024-01-30 15:28:29

For those who'd like to use up-to-date 6.1 kernel and don't mind compiling, linux-lts61 and linux-lts61-headers maintained by severach are now available on the AUR.

I gave it a try along with nvidia-535xx-dkms 535.154.05-1 (AUR), all good. Successfully suspended/resumed three times in a row, also resumed from hibernation just fine.

lorenzol36 · 2024-02-22 19:58:52

Are there any news on this? I'm still having the problem on the latest driver version. Not to say that NVENC also seems to be broken here.
This reminds me of two years ago when there was that bug that made the computer randomly freeze, which got fixed months later. NVIDIA drivers are a complete failure.

obap74 · 2024-02-22 20:31:16

lorenzol36 wrote:

Are there any news on this? I'm still having the problem on the latest driver version. Not to say that NVENC also seems to be broken here.
This reminds me of two years ago when there was that bug that made the computer randomly freeze, which got fixed months later. NVIDIA drivers are a complete failure.

According to this GTX 970 user's comment from yesterday on NVIDIA forums, 550 driver beta fixes the issue.

I'll try to switch to nvidia-beta from the AUR and see how it goes.

Edit: I switched to nvidia-beta-dkms 550.40.07-2 (AUR) and did a couple of tests. I'm not using PreserveVideoMemoryAllocation.

with linux 6.7.5.arch1-1: resumed from suspend three times in a row and then from hibernation just fine. Did this sequence again (3 suspend, 1 hibernate) after a reboot: same behavior, all good.
with linux-lts 6.6.17-1: still broken I guess. First attempt: resumed from suspend twice in a row, failed third time. Second attempt after rebooting: couldn't resume after first suspend.

At least it seems that 6.7 + 550 combo fixes the issue for good. I'm curious to know other users results, feel free to share them if you try 550 beta driver.

Last edited by obap74 (2024-02-22 22:12:05)

Cotton · 2024-02-24 13:21:42

Cotton wrote:

FWIW I'm getting the same problem with resuming from hibernate leading to a blank screen and unresponsive keyboard (after previously hibernating and resuming via Kodi for the past several months).
This is using the latest nvidia-470xx-dkms (470.223.02-1) package on an GTX 650 Ti, following the kernel change from 6.5.9 to 6.6.x
As I also use the Zen kernel, I've downgraded the that to 6.5.9 and hibernating works correctly again, whilst it fails with the 6.6 kernels (arch, lqx, ck etc).

Just updated to the latest 470.239.06 (22-Feb-2024) but that hasn't fixed it with the latest 6.7.6 kernels.

juneidy · 2024-02-26 01:00:21

https://archlinux.org/packages/extra-te … 64/nvidia/

550 is already in extra-testing

obap74 · 2024-02-27 21:23:13

I've just updated to 550.54.14 (now in extra).

While the issue seemed to be fixed on my end with 550.40.07-2 beta and 6.7 kernel (see my previous post), well, it's back with 550.54.14.

I still cannot resume from suspend/hibernate with linux 6.7.6.arch1-1 / nvidia 550.54.14-1 and linux-lts 6.6.18-1 / nvidia-lts 1:550.54.14-1. All I get is a blank screen, and the monitor eventually goes to deep sleep. Just like before.

Any other GTX 970 user having better luck?

juneidy · 2024-02-28 01:06:19

Upgraded to extra/nvidia 550.54.14-1 and core/linux 6.7.6.arch1-1

Resume from suspend gives a blank screen, but I notice switching to ctrl+alt+F2 (gives blank screen as well) then to ctrl+alt+F7 gives back my lock screen.

It is a bit annoying, but much better than not being able to get back at all.

Edit: GTX 970

Last edited by juneidy (2024-02-28 01:08:47)

lorenzol36 · 2024-02-28 12:28:50

juneidy wrote:

Resume from suspend gives a blank screen, but I notice switching to ctrl+alt+F2 (gives blank screen as well) then to ctrl+alt+F7 gives back my lock screen.

This sometimes happened to me with old drivers too, so it's not to be attributed to the new version.

EDIT: I've also updated to the latest drivers and the problem persists. GTX950 here. Also, NVENC is still broken (working fine with nvidia-utils 545.29.06-1).

Last edited by lorenzol36 (2024-02-28 23:30:23)

Gooberslot · 2024-03-03 16:53:15

I'm using a GTX 980 Ti and I also can't resume from suspend with anything newer than 535.

juneidy · 2024-03-04 23:42:33

lorenzol36 wrote:

juneidy wrote:
Resume from suspend gives a blank screen, but I notice switching to ctrl+alt+F2 (gives blank screen as well) then to ctrl+alt+F7 gives back my lock screen.
This sometimes happened to me with old drivers too, so it's not to be attributed to the new version.

I never managed to do that with 545 driver, but I am now consistently able to switch ctrl+alt+F2 and ctrl+alt+F7 to get back to my desktop on 550. So I am going to call this a win.

obap74 · 2024-03-05 10:44:41

juneidy wrote:

I never managed to do that with 545 driver, but I am now consistently able to switch ctrl+alt+F2 and ctrl+alt+F7 to get back to my desktop on 550.

Doesn't work here with AwesomeWM and physlock. Which DE/WM/screen locker are you using? Ctrl+Alt+F7 for TTY7 sounds like SDDM default so maybe Plasma?

juneidy wrote:

So I am going to call this a win.

More like a workaround (for you) for a regression in my opinion. One shouldn't have to do this... With 6.1 kernel + 535 driver, my PC always resumes to correct TTY (1 in my case) with physlock, like it's supposed to.

juneidy · 2024-03-06 00:40:35

obap74 wrote:

Doesn't work here with AwesomeWM and physlock. Which DE/WM/screen locker are you using? Ctrl+Alt+F7 for TTY7 sounds like SDDM default so maybe Plasma?

I run lightdm with AwesomeWM and xscreensaver.

obap74 wrote:

More like a workaround (for you) for a regression in my opinion. One shouldn't have to do this... With 6.1 kernel + 535 driver, my PC always resumes to correct TTY (1 in my case) with physlock, like it's supposed to.

Yeah, like I said, I was not able to get back my desktop at all with 545. Having a workaround is good enough for the time being while waiting for a more stable fix from nvidia.

Arch Linux

#76 2024-01-10 21:47:44

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#77 2024-01-10 22:18:27

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#78 2024-01-11 10:14:22

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#79 2024-01-11 10:35:07

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#80 2024-01-11 11:22:24

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#81 2024-01-11 14:10:40

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#82 2024-01-11 14:36:30

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#83 2024-01-15 00:31:34

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#84 2024-01-15 08:35:44

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#85 2024-01-21 18:04:59

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#86 2024-01-21 20:03:11

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#87 2024-01-21 20:34:11

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#88 2024-01-25 14:21:11

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#89 2024-01-30 15:28:29

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#90 2024-02-22 19:58:52

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#91 2024-02-22 20:31:16

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#92 2024-02-24 13:21:42

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#93 2024-02-26 01:00:21

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#94 2024-02-27 21:23:13

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#95 2024-02-28 01:06:19

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#96 2024-02-28 12:28:50

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#97 2024-03-03 16:53:15

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#98 2024-03-04 23:42:33

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#99 2024-03-05 10:44:41

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#100 2024-03-06 00:40:35

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

Board footer