NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

obap74 · 2023-11-25 19:16:17

kroylar wrote:

linux-lts 6.1.62-1
nvidia-lts 1:545.29.02-3
With this combination, resume is working for me.

Lucky you, it doesn't here. As juneidy said, different GPUs seem to give different results. What GPU are you using?

Cotton wrote:

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).

Indeed, there's something wrong with the 6.6 kernel too I think. The issue occurs on my end with 6.6 and newer with NVIDIA 535, even on my Gentoo install.
I was going to ask if you had tried 6.5.9 + 535 instead of 470, but I guess you're stuck with 470 considering you're using a 650 Ti?

Cotton · 2023-11-25 21:12:32

@obap74 Never used 535 and not sure it's even compatible. Not keen to experiment in case it (further) borks my main system.

I suspect the regression will eventually be fixed in an up-issued kernel.

loqs · 2023-11-29 16:14:24

Cotton wrote:

@obap74 Never used 535 and not sure it's even compatible.

535.113.01 is at least build compatible with linux 6.6 as nvidia 535.113.01-9 was built using linux 6.6.arch1-1 [1]. Did you ever test nvidia 535 with linux 6.6? Is there an upstream nvidia bug report?

[1]: https://gitlab.archlinux.org/archlinux/ … c553312dc0

Cotton · 2023-11-29 22:11:28

I meant I wasn't sure if 535 was compatible with my GeForce 650 Ti. And so, I haven't tested 535.

Have just tried the 6.6.3 kernel but no change.

loqs · 2023-11-29 22:30:42

Cotton wrote:

I meant I wasn't sure if 535 was compatible with my GeForce 650 Ti. And so, I haven't tested 535.

No the 470 series you are using is that last to support Kepler.

juneidy · 2023-12-04 06:03:26

Tried linux-6.6.3.arch1-1 and nvidia-545.29.06-2 on my GTX 970, wake from suspend issue is still present.

Adrian5 · 2023-12-06 14:37:32

Likewise issues with resume from lock here (I don't suspend) on X11. GTX970 with 6.6.4-arch1-1 and nvidia-545.29.06. I also lost KMS (high res buffer) recently and can't get it back — not sure if related. Kudos to obap74 and seth for the thorough exploration.

Last edited by Adrian5 (2023-12-06 14:40:20)

seth · 2023-12-06 14:47:04

I also lost KMS (high res buffer)

??
Please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

obap74 · 2023-12-06 14:56:59

Madeorsk wrote:

Like obap74, I use a GTX 970. When I upgraded my system recently, I noticed that I couldn't resume from suspend since I upgraded (from 535.104.05 to 545.29.02 for the nvidia driver).

juneidy wrote:

Tried linux-6.6.3.arch1-1 and nvidia-545.29.06-2 on my GTX 970, wake from suspend issue is still present.

Adrian5 wrote:

GTX970 with 6.6.4-arch1-1

That's quite a lot of GTX 970 users (including me). And also Cotton with a GTX 650 Ti.

Adrian5 wrote:

Likewise issues with resume from lock here (I don't suspend) on X11. GTX970 with 6.6.4-arch1-1 and nvidia-545.29.06.

Might be a different issue, what do you mean by "resume from lock"?

seth · 2023-12-06 15:01:21

Cinnamon?

Adrian5 · 2023-12-06 15:45:52

obap74 wrote:

Might be a different issue, what do you mean by "resume from lock"?

I meant that I don't suspend the system. Just the screen lock (using Xfce with LightDM and lightdm-gtk-greeter) causes this, whether triggered by power management or manually by myself. The resulting behavior is very close to what you describe in your original post (black void with mouse pointer).

seth wrote:

I also lost KMS (high res buffer)
??
Please post your complete system journal for the boot…

The boot sequence and TTYs run in a low resolution now, which they didn't until recently. Before reading your reply I noticed a new (unfamiliar) error:

kernel: [drm:drm_new_set_master] *ERROR* [nvidia-drm] [GPU ID 0x00000200] Failed to grab modeset ownership

I searched and supposedly it's benign. So I can't tell if it's related to the graphical UI breaking or simply caused by me switching TTYs to salvage the system. It's tied to one of these events and will not occur prior. I don't want to derail this thread if it's unrelated.

Edit: nvidia boot messages look nominal to me:

[4.411635] nvidia-nvlink: Nvlink Core is being initialized, major device number 235
[4.412812] nvidia 0000:02:00.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=none:owns=io+mem
[4.529494] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  545.29.06  Thu Nov 16 01:59:08 UTC 2023
[4.562769] intel_rapl_common: Found RAPL domain package
[4.562773] intel_rapl_common: Found RAPL domain core
[4.616422] nvidia_uvm: module uses symbols nvUvmInterfaceDisableAccessCntr from proprietary module nvidia, inheriting taint.
[4.784753] nvidia-uvm: Loaded the UVM driver, major device number 511.
[4.826011] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  545.29.06  Thu Nov 16 01:47:29 UTC 2023
[4.832018] [drm] [nvidia-drm] [GPU ID 0x00000200] Loading driver
[5.355029] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[5.355305] Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[5.357578] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[5.357581] cfg80211: failed to load regulatory.db
[5.494731] [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:02:00.0 on minor 0

Last edited by Adrian5 (2023-12-06 16:00:38)

bertieb · 2023-12-06 16:51:59

obap74 wrote:

Madeorsk wrote:
Like obap74, I use a GTX 970. When I upgraded my system recently, I noticed that I couldn't resume from suspend since I upgraded (from 535.104.05 to 545.29.02 for the nvidia driver).
juneidy wrote:
Tried linux-6.6.3.arch1-1 and nvidia-545.29.06-2 on my GTX 970, wake from suspend issue is still present.
Adrian5 wrote:
GTX970 with 6.6.4-arch1-1
That's quite a lot of GTX 970 users (including me). And also Cotton with a GTX 650 Ti.

Me as well, for another data point.

At the moment I'm back on 6.5.8 and nvidia-535, it'd be good to know when updating is possible again!

seth · 2023-12-06 19:31:26

seth wrote:

Please post your complete system journal for the boot…

On a limb, enable https://wiki.archlinux.org/title/NVIDIA … de_setting and in doubt add "initcall_blacklist=simpledrm_platform_driver_init" to the https://wiki.archlinux.org/title/Kernel_parameters

v2vm · 2023-12-29 22:23:33

i'm on the latest linux-lts and nvidia-lts (also tried nvidia-dkms), xfce4, x11, no display manager

similar issue: when resuming from suspend, i can see a working cursor with a black screen but nothing else, able to switch to another tty

obap74 · 2023-12-30 11:09:48

v2vm wrote:

i'm on the latest linux-lts and nvidia-lts (also tried nvidia-dkms), xfce4, x11, no display manager
similar issue: when resuming from suspend, i can see a working cursor with a black screen but nothing else, able to switch to another tty

Sounds like a slightly different issue. No cursor and I cannot switch to any tty on my end. Was it working fine on 535? See this.

Ekce · 2024-01-08 21:26:50

Adrian5 wrote:

I meant that I don't suspend the system. Just the screen lock (using Xfce with LightDM and lightdm-gtk-greeter) causes this, whether triggered by power management or manually by myself. The resulting behavior is very close to what you describe in your original post (black void with mouse pointer).

I have the same resulting behavior. My setup is XFCE with LightDM using web-greeter, on Kernel 6.6.10.arch1-1 with an Nvidia GTX 1660 using the 545.29.06-1 drivers. I also have 3 monitors and a display-setup-script line in `lightdm.conf` but I don't know if that matters. I get this behavior when I idle for an amount of time and let the computer suspend, I haven't tried manually triggering a suspend. However, I don't get the behavior consistently. I've gotten it for quite some time, at least since sometime in November but possibly much longer (I'd just been far too busy to even look into it). Sometimes, after doing updates the behavior will improve and sometimes it will get worse (happen more consistently). Currently it's happening almost every time I enter a suspend state. I've observed it happening several times now without any programs open (I'll boot up, log in, wait, and have this happen) -- so I don't attribute it to running out of ram or some program causing issues.

On rare occasions, when I log in I'll get this behavior (black void with mouse cursor) but after a pause the desktop will show up.
On other rare occasions the cursor in the black void will change between a pointer or a text cursor depending on where it is on the screen (as if the desktop is loading but not visible) but when I click it gets stuck as one type of pointer.
On even rarer occasions I don't get a cursor, instead it's almost like I got dropped into the terminal and I just see a black void with a line. In this case I can't switch TTY (e.g. ctrl+alt+F2 does nothing).

I am consistently seeing errors like this in `journalctl` that seem to coincide with the failure:

Jan 08 10:40:13 enki kernel: [drm:drm_new_set_master] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to grab modeset ownership
Jan 08 10:40:13 enki kernel: [drm:drm_new_set_master] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to grab modeset ownership

seth · 2024-01-08 22:03:42

I am consistently seeing errors like this in `journalctl` that seem to coincide with the failure:

Remove "nvidia_drm.fbdev=1" and instead make sure that "nvidia_drm.modeset=1" is in the kernel commandline to disable the simpledrm device.
(Not sure though whether the fbdev issues are related to the S3 resume)

Ekce · 2024-01-08 22:34:42

seth wrote:

I am consistently seeing errors like this in `journalctl` that seem to coincide with the failure:
Remove "nvidia_drm.fbdev=1" and instead make sure that "nvidia_drm.modeset=1" is in the kernel commandline to disable the simpledrm device.
(Not sure though whether the fbdev issues are related to the S3 resume)

This is what's in my bootloader's kernel paramters. I haven't used `fbdev=1` before.

options	root=PARTUUID="" rw fsck.mode=force nvidia_drm.modeset=1 nvidia.NVreg_UsePageAttributeTable=1 nvidia.NVreg_EnablePCIeGen3=1

Note, I removed the UUID from the above.

seth · 2024-01-08 22:36:32

Is

modprobe -c | grep fbdev

empty?

Ekce · 2024-01-08 22:40:06

Strangely no, I get:

modprobe -c | grep fbdev
alias symbol:drm_fbdev_dma_setup drm_dma_helper

seth · 2024-01-08 22:41:47

That's unrelated, though - you don't have fbdev enabled.

bertieb · 2024-01-10 12:16:18

A issue the same as or very similar to this was raised on the nvidia Linux forum last month.

In the meantime, what is the best practice for handling this situation from an Arch user perspective? I am aware partial upgrades are not supported, and IgnorePkg is discouraged. At the moment I am not sure if a kernel upgrade past 6.5.8 is safe / usable, and I am reasonable sure upgrading nvidia is not (a system that cannot be suspended is technically usable, albeit very inconvenient or wasteful). I know I don't have to upgrade regularly, but it is recommended.

Asking in this thread as the advice may benefit others in the same situation!

Last edited by bertieb (2024-01-10 13:55:11)

FMB · 2024-01-10 13:13:10

bertieb wrote:

A issue the same as or very similar to this was raised on the nvidia Linux forum last month.

The symptoms are similar indeed.

obap74 · 2024-01-10 13:58:47

bertieb wrote:

A issue the same as or very similar to this was raised on the nvidia Linux forum last month.
In the meantime, what is the best practice from an Arch user perspective? I am aware partial upgrades are not supported, and IgnorePkg is discouraged. At the moment I am not sure if a kernel upgrade past 6.5.8 is safe / usable, and I am reasonable sure upgrading nvidia is not (a system that cannot be suspended is technically usable, albeit very inconvenient or wasteful). I know I don't have to upgrade regularly, but it is recommended.
Asking in this thread as the advice may benefit others in the same situation!

I'm using Gentoo as my main distro, which allows me to stick with 6.1 kernel and NVIDIA 535. As you say, this would be considered as a partial upgrade on Arch. Not to mention that linux-lts is now 6.6 on Arch as well.

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.

bertieb · 2024-01-10 21:38:22

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?

Arch Linux

#51 2023-11-25 19:16:17

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#52 2023-11-25 21:12:32

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#53 2023-11-29 16:14:24

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#54 2023-11-29 22:11:28

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#55 2023-11-29 22:30:42

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#56 2023-12-04 06:03:26

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#57 2023-12-06 14:37:32

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#58 2023-12-06 14:47:04

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#59 2023-12-06 14:56:59

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#60 2023-12-06 15:01:21

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#61 2023-12-06 15:45:52

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#62 2023-12-06 16:51:59

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#63 2023-12-06 19:31:26

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#64 2023-12-29 22:23:33

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#65 2023-12-30 11:09:48

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#66 2024-01-08 21:26:50

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#67 2024-01-08 22:03:42

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#68 2024-01-08 22:34:42

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#69 2024-01-08 22:36:32

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#70 2024-01-08 22:40:06

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#71 2024-01-08 22:41:47

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#72 2024-01-10 12:16:18

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#73 2024-01-10 13:13:10

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#74 2024-01-10 13:58:47

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

#75 2024-01-10 21:38:22

Re: NVIDIA - cannot resume from suspend with PreserveVideoMemoryAllocation

Board footer