Desktop session doesn't survive suspend after changing to NVidia

[commander_trout]

I recently changed from AMD to NVidia for graphics and since then my desktop session doesn’t survive suspend. When waking my machine up after suspending overnight, I get a flashing cursor in the top left. My solution is to switch to a text-based virtual console (CTRL+ALT+F2) and I restart lightdm using,

$ sudo systemctl restart lightdm.service

This means that I don’t need to reboot my system, but I clearly lose all my desktop session state.

I suspend my machine using the following i3 binding,

bindsym s exec --no-startup-id i3exit suspend, mode "default"

which worked fine for a couple of years with the AMD graphics card.

It’s definitely worth noting that if I suspend for a short amount of time (1 minute), the system and desktop session come out of suspend without problem. As a result, it’s hard to test different solutions.

System:
  Host: stefan-desktop Kernel: 5.15.55-1-MANJARO arch: x86_64 bits: 64
    Desktop: i3 v: 4.20.1 Distro: Manjaro Linux
Machine:
  Type: Desktop System: Gigabyte product: B450M DS3H v: N/A
    serial: <superuser required>
  Mobo: Gigabyte model: B450M DS3H-CF serial: <superuser required>
    UEFI: American Megatrends LLC. v: F62d date: 10/13/2021
CPU:
  Info: 8-core AMD Ryzen 7 2700 [MT MCP] speed (MHz): avg: 1671
    min/max: 1550/3200
Graphics:
  Device-1: NVIDIA TU106 [GeForce RTX 2060 12GB] driver: nvidia v: 515.57
  Device-2: Jieli USB PHY 2.0 type: USB driver: snd-usb-audio,uvcvideo
  Display: x11 server: X.Org v: 21.1.4 driver: X: loaded: nvidia
    gpu: nvidia resolution: 1: 3840x2160~60Hz 2: 3840x2160~60Hz
  OpenGL: renderer: NVIDIA GeForce RTX 2060/PCIe/SSE2
    v: 4.6.0 NVIDIA 515.57
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
    driver: r8169
Drives:
  Local Storage: total: 342.81 GiB used: 256.37 GiB (74.8%)
Info:
  Processes: 473 Uptime: 15d 23h 15m Memory: 31.27 GiB used: 1.85 GiB (5.9%)
  Shell: Zsh inxi: 3.3.19

[anon89812132]

From a fresh boot, if you run:
systemctl suspend

Do you notice any difference?

Might be relevant the part with early KMS in Power management/Suspend and hibernate - ArchWiki

For Nvidia GPU and drivers you have to do it like this:

Switching to Nvidia drivers from Nouveau with mhwd fails

sudo mhwd -r pci video-linux then sudo mhwd -i pci video-nvidia On gnome you might have to enable early kms. As administrator edit the /etc/mkinitcpio.conf and make the MODULES= line like this MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm) then run from terminal: sudo mkinitcpio -P sudo update-grub Also, you probably have autologin on and is trying wayland session and not always starts (at least on my end does funky things)

[commander_trout]

Thanks for the reply. I might try using systemctl suspend instead of the existing method I’m using to suspend and see if that makes a difference.

This part of the linked article would seem to be closes to what I’m experiencing,

Sometimes the screen goes black due to device initialization from within the initramfs. Removing any modules you might have in Mkinitcpio#MODULES and rebuilding the initramfs, can possibly solve this issue, specially graphics drivers for early KMS. Initializing such devices before resuming can cause inconsistencies that prevents the system resuming from hibernation. This does not affect resuming from RAM. Also, check the blog article best practices to debug suspend issues.

[commander_trout]

I’ve looked a bit deeper into how I’m normally suspending my machine. I call i3exit suspend, which is actually calling systemctl suspend behind the scenes. However, i3exit suspend also calls blurlock, which calls i3lock using a blurred screenshot of the desktop. So calling systemctl suspend on its own would be simpler.

I’m not able to replicate the problem directly, instead I seem to need to leave the machine suspended for some time (like overnight) to replicate. I’ve replaced i3exit suspend with systemctl suspend, i.e. removed the call to blurlock.

Failing that, I will try calling systemctl suspend after a fresh boot.

[commander_trout]

I tried a plain systemctl suspend overnight and encountered the same problem this morning, i.e. removing the blurlock made no difference.

Tonight I will try system suspend after a fresh boot.

[frost19k]

Bumping to say that this issue’s been a problem for a while.

My post on this:

Failure to resume (freeze) after long suspend

For the past couple of months my desktop has been failing to resume from a long suspend. It resumes successfully if it’s woken up fairly quickly (thirty minutes to an hour). But it freezes - back-light on, black screen, unblinking cursor in top left corner - if it’s left to sleep for several hours. There is nothing in the journal. It just stops…

journalctl -rb -1

Jun 27 04:42:43 manjaro-ws.local kernel: userif-6: sent link up event. Jun 27 04:42:43 manjaro-ws.local kernel: PM: suspend entry (…

Arch Wiki post on it:
https://bbs.archlinux.org/viewtopic.php?id=273677

I don’t have a solution for you but I’m hoping that someone else does & we can both profit.

[commander_trout]

I have just had some success!

@anon89812132 suggested systemctl suspend after a fresh boot. So what I did was

• reboot my machine
• login to a graphical environment (i3)
• start a terminal (alacritty) and run systemctl suspend

When I woke my machine up in the morning, I got my graphical environment back, but I did need to unlock my screen even though I didn’t explicitly lock before suspending.

Could this mean the problem might lie with some process running in userspace? Too soon to tell. Hard to tell.

It’s worth nothing that I had done a system upgrade in the lead up (inxi output below).

I normally tend to have the following running when I suspend,

• docker daemon
• brave (a couple of profiles, many instances)
• chromium (a couple of profiles, many instances)
• firefox (several instances)
• alacritty (many instances)

System:
  Host: stefan-desktop Kernel: 5.15.60-1-MANJARO arch: x86_64 bits: 64
    Desktop: i3 v: 4.20.1 Distro: Manjaro Linux
Machine:
  Type: Desktop System: Gigabyte product: B450M DS3H v: N/A
    serial: <superuser required>
  Mobo: Gigabyte model: B450M DS3H-CF serial: <superuser required>
    UEFI: American Megatrends LLC. v: F62d date: 10/13/2021
CPU:
  Info: 8-core AMD Ryzen 7 2700 [MT MCP] speed (MHz): avg: 1503
    min/max: 1550/3200
Graphics:
  Device-1: NVIDIA TU106 [GeForce RTX 2060 12GB] driver: nvidia v: 515.65.01
  Device-2: Logitech Webcam C170 type: USB driver: snd-usb-audio,uvcvideo
  Display: x11 server: X.Org v: 21.1.4 driver: X: loaded: nvidia
    gpu: nvidia resolution: 1: 3840x2160~60Hz 2: 3840x2160~60Hz
  OpenGL: renderer: NVIDIA GeForce RTX 2060/PCIe/SSE2 v: 4.6.0 NVIDIA
    515.65.01
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
    driver: r8169
Drives:
  Local Storage: total: 342.81 GiB used: 254.7 GiB (74.3%)
Info:
  Processes: 311 Uptime: 12h 46m Memory: 31.27 GiB used: 3.46 GiB (11.1%)
  Shell: Zsh inxi: 3.3.21

[anon89812132]

Is i3exit already having this in it?

#!/bin/sh
lock() {
  i3lock
}

case "$1" in
  lock)
    lock
    ;;
  logout)
    i3-msg exit
    ;;
  suspend)
    lock && systemctl suspend
    ;;
  hibernate)
    lock && systemctl hibernate
    ;;
  reboot)
    systemctl reboot
    ;;
  shutdown)
    systemctl poweroff
    ;;
  *)
    echo "Usage: $0 {lock|logout|suspend|hibernate|reboot|shutdown}"
    exit 2
esac
                                                                                                                                                
exit 0

and i3config should have the $mode_system like this:

set $mode_system System (l) lock, (e) logout, (s) suspend, (h) hibernate, (r) reboot, (Shift+s) shutdown
mode "$mode_system" {
    bindsym l exec --no-startup-id i3exit lock, mode "default"
    bindsym e exec --no-startup-id i3exit logout, mode "default"
    bindsym s exec --no-startup-id i3exit suspend, mode "default"
    bindsym h exec --no-startup-id i3exit hibernate, mode "default"
    bindsym r exec --no-startup-id i3exit reboot, mode "default"
    bindsym Shift+s exec --no-startup-id i3exit shutdown, mode "default"  
                        
    # back to normal: Enter or Escape
    bindsym Return mode "default"
    bindsym Escape mode "default"
}
bindsym $mod+End mode "$mode_system"

So not quite sure, but should work. On the other hand, there is always betterlockscreen that seems more refined, different a bit tho …

[commander_trout]

@anon89812132 Yes, you’re right - i3exit does lock before suspend and it calls systemctl suspend behind the scenes.

Last night, I

• logged out of my i3 session
• logged back in to a fresh i3 session
• started a terminal (alacritty) and ran systemctl suspend, i.e. I didn’t use i3exit

This morning I was able to wake up from suspend back into my i3 session . Again I did have to unlock my screen, so something is implicitly locking my screen between running systemctl suspend and me waking my machine up 12hrs later.

Obviously, the goal is to be able to call i3exit suspend in the middle of an i3 session and then be able to wake the machine up some time later an recover that same i3 session. Any tips on what I should try next?

[commander_trout]

I think I’m finally able to replicate the problem!

• suspend my machine, systemctl suspend
• turn off my monitors (2 x Dell 4K configured as a single joined monitor)
• wake up my machine (keyboard keypress)
• turn on my monitors

I believe the issue here is waking my machine up before my monitors have been turned on.