Black screen (with mouse) when resuming suspend - Nvidia

Lem0nHead · 2024-05-12 15:12:55

I didn't update Arch Linux for the last 6 months and after last update I started having issues when resuming from suspend.

My screen gets black and I can move mouse. At first I though this could be a xscreensaver issue and tried killing it in a text terminal, but it didn't work.
Then I found out I could alternate to another X session (ctrl-alt-F1) and try to login, but I also get a black screen.

Only thing that "solves" it is rebooting my laptop.

Checking other posts and wikis, I tried:
* Enabling `nvidia_drm.modeset=1` (kernel param)
* Enabling `nvidia-resume.service` and `nvidia-suspend.service`

None of that worked.

Nvidia 550.78
Xfce 4.18
GTK 3.24.41

$ sudo X -version
X.Org X Server 1.21.1.13
X Protocol Version 11, Revision 0
Current Operating System: Linux archlinux 6.6.30-2-lts #1 SMP PREEMPT_DYNAMIC Tue, 07 May 2024 21:45:29 +0000 x86_64
Kernel command line: (...) quiet acpi_backlight=vendor nvidia_drm.modeset=1

$ systemctl list-unit-files | grep -i nvidia
nvidia-hibernate.service                     disabled        disabled
nvidia-persistenced.service                  disabled        disabled
nvidia-powerd.service                        disabled        disabled
nvidia-resume.service                        enabled         disabled
nvidia-suspend.service                       enabled         disabled

dmesg shows some (even before the problem happens):

[Sun May 12 15:59:20 2024] nvidia-modeset: WARNING: GPU:0: BOE Technology Group Co., Ltd (DP-0): G-SYNC Compatible: EDID min refresh rate invalid, disabling G-SYNC Compatible.
[Sun May 12 16:05:21 2024] [drm:drm_new_set_master] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to grab modeset ownership

I also found this on journalctl:

May 12 15:01:32 archlinux /usr/lib/gdm-x-session[53676]: (II) NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon
May 12 15:01:32 archlinux /usr/lib/gdm-x-session[53676]: (II) NVIDIA(0):     may not be running or the "AcpidSocketPath" X
May 12 15:01:32 archlinux /usr/lib/gdm-x-session[53676]: (II) NVIDIA(0):     configuration option may not be set correctly.  When the
May 12 15:01:32 archlinux /usr/lib/gdm-x-session[53676]: (II) NVIDIA(0):     ACPI event daemon is available, the NVIDIA X driver will
May 12 15:01:32 archlinux /usr/lib/gdm-x-session[53676]: (II) NVIDIA(0):     try to use it to receive ACPI event notifications.  For
May 12 15:01:32 archlinux /usr/lib/gdm-x-session[53676]: (II) NVIDIA(0):     details, please see the "ConnectToAcpid" and
May 12 15:01:32 archlinux /usr/lib/gdm-x-session[53676]: (II) NVIDIA(0):     "AcpidSocketPath" X configuration options in Appendix B: X
May 12 15:01:32 archlinux /usr/lib/gdm-x-session[53676]: (II) NVIDIA(0):     Config Options in the README.

Any other ideas I could try before I try to bisect downgrading kernel/nvidia drivers?

Thanks

Last edited by Lem0nHead (2024-05-12 15:15:41)

Lem0nHead · 2024-05-13 15:39:50

I also tried adding `NVreg_PreserveVideoMemoryAllocations=1`to kernel params, but no success.

seth · 2024-05-13 17:22:52

My screen gets black and I can move mouse.

Xfce 4.18

Try to disable https://wiki.archlinux.org/title/Xfwm#Composite_manager

I also tried adding `NVreg_PreserveVideoMemoryAllocations=1`to kernel params, but no success.

This is not correct, it's a module parameter - the syntax in the kernel commandline would be "nvidia.NVreg_PreserveVideoMemoryAllocations=1" and it is required for the nvidia-suspend and -resume services to work (which in turn should work around the VRAM decay which then should prevent the black textures you're likely seeing in your compositor)

The services will warn you if the parameter isn't correctly set, check the system journal.

Lem0nHead · 2024-05-19 13:54:58

I tried to isolate a few more variables, but nothing helped.

Instead of using kernel params, I'm now doing:

$ cat /etc/modprobe.d/nvidia.conf 
options nvidia NVreg_PreserveVideoMemoryAllocations=1

I tried with and without `nvidia_drm.modeset=1` and none solve the issue.

So far I've successfully suspended/resumed without the problem, but about 50% of the times it does display the problem.

The exact problem is that when it resumes, the screen is all blank on terminal 2. If I switch to terminal 1, I can see a login screen and I can even login, but it seems to get logged out and returns to the login screen. The second terminal still shows nothing.

If I open the 3rd terminal, I can use text mode and reboot, for example, but I couldn't find anything obvious on dmesg or Xorg logs

seth · 2024-05-19 14:35:44

If you've the nvidia module in your initramfs you've to regenerate that after adding the modprobe config to have it apply.
Alternatively the correct kernel parameter will always apply.

Lem0nHead · 2024-05-19 20:39:12

seth wrote:

If you've the nvidia module in your initramfs you've to regenerate that after adding the modprobe config to have it apply.
Alternatively the correct kernel parameter will always apply.

not very familiar with initramfs, but my understanding is that this means nvidia is not on it:

$ sudo lsinitcpio /boot/initramfs-linux-lts.img  | grep -i nvidia
usr/lib/modprobe.d/nvidia-utils.conf

also:

$ sudo cat /proc/driver/nvidia/params | grep -i preser
PreserveVideoMemoryAllocations: 1

Last edited by Lem0nHead (2024-05-19 20:39:56)

seth · 2024-05-19 22:26:47

Yes does, and the parameter gets applied.

Is the storage location big enough™?
If you're short on RAM and have lots of VRAM, storing the VRAM in the RAM won't work.

Just to be sure we're not chasing some wild geese: did you test the behavior w/ the compositor disabled and did that prevent the issue?

Lem0nHead · 2024-05-21 21:32:04

seth wrote:

did you test the behavior w/ the compositor disabled and did that prevent the issue?

do you mean xfce tweaks -> Compositor?
I tried disabling "Display fullscreen overlay" if that's what you mean but I didn't disable it completely because it becomes a mess

What I tried to do though is `xfce4-power-manager -q`

I also have enough RAM

I will try another system update today.. if it doesn't fix it I'll try a kernel+nvidia driver downgrade, let's see what happens

seth · 2024-05-21 21:46:48

because it becomes a mess

What does that mean? Disabling the compositor should™ be just fine?

Lem0nHead · 2024-05-22 16:53:22

[ignore, double posted below]

Last edited by Lem0nHead (2024-05-22 16:55:07)

Lem0nHead · 2024-05-22 16:54:44

seth wrote:

because it becomes a mess
What does that mean? Disabling the compositor should™ be just fine?

OH! It looks like disabling the compositor actually works!

Perhaps this is some bad interaction of the compositor with xscreensaver

Disabling it cause the screen to now refresh apparently. For example, if I minimize a window, its content stays on the screen (unless there's a window behind it).

seth · 2024-05-23 07:16:28

Doesn't xfce use some desktop window?
Do you use some GL screensaver?

As workaround you could stop and start the compositor around the sleep, https://wiki.archlinux.org/title/Power_ … stem-sleep (those scripts run as root and you'll have to import the relevant environment and sudo your UID, see eg. https://gist.github.com/AladW/de1c5676d93d05a5a0e1 )

Lem0nHead · 2024-05-23 22:06:55

seth wrote:

Doesn't xfce use some desktop window?

not sure, apparently not

seth wrote:

Do you use some GL screensaver?

yeah, xscreensaver
I tried killing it from another terminal when the problem happened and this didn't help

that's what I've always used, why do you ask?

seth wrote:

As workaround you could stop and start the compositor around the sleep

as much as I like a workaround, I'd rather change/downgrade the screensaver instead of risking this kind of change biting me in the future because I forget I have this script and it conflicts with something else

seth · 2024-05-23 22:25:03

xscreensaver comes with a series of fancy animations - some are implemented in GL, others aren't.
You can also just straight up lock the screen without any fancy stuff.

=> What screensaver animation do you use?
Does the issue remain if you use none and just lock the screen?

Lem0nHead · 2024-05-24 00:40:59

seth wrote:

xscreensaver comes with a series of fancy animations - some are implemented in GL, others aren't.
You can also just straight up lock the screen without any fancy stuff.
=> What screensaver animation do you use?
Does the issue remain if you use none and just lock the screen?

yes, that's what I use, Mode: blank screen only

seth · 2024-05-24 06:26:57

Together w/

I tried killing it from another terminal when the problem happened and this didn't help

this does not sound the likely cause?
Does it consistenly happen w/ xfwm4 composition + xscreensaver and NEVER w/ xfwm4 composition - xscreensaver ?
You can try i3lock or slock as alternatives… or just https://archlinux.org/packages/extra/x8 … reensaver/ ?
But I doubt that this will fix it for good.

I'd rather try w/o GDM.
Does that currently run on the X11 or the wayland backend?

Lem0nHead · 2024-05-24 23:04:32

seth wrote:

Together w/
I tried killing it from another terminal when the problem happened and this didn't help
this does not sound the likely cause?
Does it consistenly happen w/ xfwm4 composition + xscreensaver and NEVER w/ xfwm4 composition - xscreensaver ?
You can try i3lock or slock as alternatives… or just https://archlinux.org/packages/extra/x8 … reensaver/ ?
But I doubt that this will fix it for good.

yeah, I don't have much faith on that also. I suppose I assumed the issue was related to xscreensaver because I expected to see its login popup when resuming from suspend and was not. It always shows up when just locking though (without suspending).

I did some additional experiments today though. First thing I noticed was some `May 24 23:32:16 archlinux /usr/lib/gdm-x-session[1153]: (II) systemd-logind: got pause for 13:71` on journalctl

Not sure if related, but some people reported similar issues as mine and also had this message (I didn't find a solution though).

seth wrote:

I'd rather try w/o GDM.
Does that currently run on the X11 or the wayland backend?

I use X11, I tried regenerating xorg.conf just because mine is from 2017, but this didn't help.

Not sure I get what you mean by trying w/o GDM, but that gave some hints.

After a black screen issue, I openedd another terminal and restart gdm - this allowed me to login again from terminal 1.
Then if I just move back to the text terminal and return to terminal 1, I see the login screen, it allows me to login, but I get black screen after typing my user/pw

If I go to terminal 3 and restart gdm again, I can repeat that

So at least now I managed to cause the issue without suspending, which seems to narrow it down a bit - and perhaps correlate it to system-logind, but I'm again out of ideas

Lem0nHead · 2024-05-24 23:17:39

Lem0nHead wrote:

Not sure I get what you mean by trying w/o GDM, but that gave some hints.

ok, I got it now

sorry, my understanding of the layers of Linux GUI is limited

I installed lightdm and ran `systemctl disable gdm && systemctl enable lightdm`

this succeeded (as in, in the next reboot I got lightdm instead of gdm), but the problem persisted. After resuming from suspend, I got a black screen.

seth · 2024-05-25 15:45:19

Then if I just move back to the text terminal and return to terminal 1, I see the login screen, it allows me to login, but I get black screen after typing my user/pw

But at this point you still are logged in?

Nvidia has issues w/ framebuffer switches and certain GL or (I've rather seen it with) vdpau contexts - if you're using grub, does https://wiki.archlinux.org/title/GRUB/T … ramebuffer help?

When you fail to resume from suspend, can you still switch the VT (apparently yes) and toggle the xfwm4 compositor from there (you may have to "export DISPLAY=:0" or "export DISPLAY=:1" first, GDM will occupy :0 and spawn your session on :1, lightdm won't) and does that bring back the session GUI?

Lem0nHead · 2024-05-26 17:27:17

seth wrote:

But at this point you still are logged in?

hm, not sure
I'd assume I'm logged in but I can't see anything on the screen

seth wrote:

Nvidia has issues w/ framebuffer switches and certain GL or (I've rather seen it with) vdpau contexts - if you're using grub, does https://wiki.archlinux.org/title/GRUB/T … ramebuffer help?

I didn't test this yet, will do on the next boot

not sure if relevant, but I've never had issues with this before.. maybe something changed on the last nvidia drivers

seth wrote:

When you fail to resume from suspend, can you still switch the VT (apparently yes) and toggle the xfwm4 compositor from there (you may have to "export DISPLAY=:0" or "export DISPLAY=:1" first, GDM will occupy :0 and spawn your session on :1, lightdm won't) and does that bring back the session GUI?

I tried with GDM and toggling xfwm4 compositor on both DISPLAY=:0 and :1, this doesn't fix the issue (neither leaving it disabled if when I suspended it was enabled)

Lem0nHead · 2024-05-26 17:33:15

seth wrote:

if you're using grub, does https://wiki.archlinux.org/title/GRUB/T … ramebuffer help?

just tried now, no
the grub menu gets more "texty" (like terminal font), but I still get black screen after suspending

I guess my next step will be to try wayland and/or downgrading drivers as I'm running out of ideas

Lem0nHead · 2024-05-26 17:35:59

hm, I just noticed something

after I get the problem once, if I restart the display-manager it gets back working (that I knew), but then the problem doesn't happen again!

at least I tried suspending and resuming 3 times and it worked (I'm keeping composition on for the tests)

Last edited by Lem0nHead (2024-05-26 17:36:20)

seth · 2024-05-26 17:41:22

What if you only boot the multi-user.target (2nd link below), get a cup of coffee and then "systemctl start graphical.target"?

Lem0nHead · 2024-05-26 22:36:36

seth wrote:

What if you only boot the multi-user.target (2nd link below), get a cup of coffee and then "systemctl start graphical.target"?

first observation was that simply running "systemctl set-default multi-user.target" froze my laptop!
it created the symlink and froze (even numlock key wasn't responding), I had to reboot it

then I rebooted and it was also on graphical, so I moved to text terminal (before login to graphical) and typed that again, which then worked after the next reboot (it rebooted to text mode)

I logged in and before starting graphical, I tried "systemctl suspend" and it also resumes back to a black screen - I definitely wasn't expecting that since it works with compositor off in xfce

I then confirmed the OS was running by (blindly) typing "reboot" and it indeed rebooted

so summarizing the current observations:
1. no kernel params/nvidia options helped
2. never happens with compositor off
3. (almost) always happens with compositor on
4. happens in multi-user.target without graphical
5. when the problem happens, I can switch to a text terminal and restart gdm, which fixes the problem (as in, it seems to kill my session and I can login again)

I'm very confused by [4], sounds like changing to wayland wouldn't help

Lem0nHead · 2024-05-26 23:52:39

after the last experiment I decided to downgrade nvidia (nvidia, nvidia-lts, nvidia-utils); I tried both -535 and -545 and apparently there is some conflict because it boots to a low-resolution (looks like 800x600) login screen and, after I type my user/pw, it doesn't start xfce

that's being a much harder issue to solve than I could expect

Arch Linux

#1 2024-05-12 15:12:55

Black screen (with mouse) when resuming suspend - Nvidia

#2 2024-05-13 15:39:50

Re: Black screen (with mouse) when resuming suspend - Nvidia

#3 2024-05-13 17:22:52

Re: Black screen (with mouse) when resuming suspend - Nvidia

#4 2024-05-19 13:54:58

Re: Black screen (with mouse) when resuming suspend - Nvidia

#5 2024-05-19 14:35:44

Re: Black screen (with mouse) when resuming suspend - Nvidia

#6 2024-05-19 20:39:12

Re: Black screen (with mouse) when resuming suspend - Nvidia

#7 2024-05-19 22:26:47

Re: Black screen (with mouse) when resuming suspend - Nvidia

#8 2024-05-21 21:32:04

Re: Black screen (with mouse) when resuming suspend - Nvidia

#9 2024-05-21 21:46:48

Re: Black screen (with mouse) when resuming suspend - Nvidia

#10 2024-05-22 16:53:22

Re: Black screen (with mouse) when resuming suspend - Nvidia

#11 2024-05-22 16:54:44

Re: Black screen (with mouse) when resuming suspend - Nvidia

#12 2024-05-23 07:16:28

Re: Black screen (with mouse) when resuming suspend - Nvidia

#13 2024-05-23 22:06:55

Re: Black screen (with mouse) when resuming suspend - Nvidia

#14 2024-05-23 22:25:03

Re: Black screen (with mouse) when resuming suspend - Nvidia

#15 2024-05-24 00:40:59

Re: Black screen (with mouse) when resuming suspend - Nvidia

#16 2024-05-24 06:26:57

Re: Black screen (with mouse) when resuming suspend - Nvidia

#17 2024-05-24 23:04:32

Re: Black screen (with mouse) when resuming suspend - Nvidia

#18 2024-05-24 23:17:39

Re: Black screen (with mouse) when resuming suspend - Nvidia

#19 2024-05-25 15:45:19

Re: Black screen (with mouse) when resuming suspend - Nvidia

#20 2024-05-26 17:27:17

Re: Black screen (with mouse) when resuming suspend - Nvidia

#21 2024-05-26 17:33:15

Re: Black screen (with mouse) when resuming suspend - Nvidia

#22 2024-05-26 17:35:59

Re: Black screen (with mouse) when resuming suspend - Nvidia

#23 2024-05-26 17:41:22

Re: Black screen (with mouse) when resuming suspend - Nvidia

#24 2024-05-26 22:36:36

Re: Black screen (with mouse) when resuming suspend - Nvidia

#25 2024-05-26 23:52:39

Re: Black screen (with mouse) when resuming suspend - Nvidia

Board footer