Unresponsive Black Screen after suspend

tranqu · 2026-04-28 14:50:03

Hi All, and thank you already for helping me with this.
I am very happy with my arch install, I am running KDE plasma and all but the suspend/hibernate works perfectly for me.
Unfortunately I can not figure out what is wrong and need help. Unfortunately (I bought it before I moved from Windows fully to Linux) I have an Nvidia RTX 4070 Ti Super graphics card, I repeatedly hear they cause issues on Linux, but I can't afford to change at the moment - so I want to get it to work if at all possible.
I followed the instructions from the arch wiki. Now recently it changed from having

NVreg_PreserveVideoMemoryAllocations

to

NVreg_UseKernelSuspendNotifiers=1

Kernel mode parameters, but my suspend just doesn't work.
I am running:

nvidia-smi                                                       
Tue Apr 28 16:29:13 2026       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 595.58.03              Driver Version: 595.58.03      CUDA Version: 13.2     |
+-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce RTX 4070 ...    On  |   00000000:01:00.0  On |                  N/A |
|  0%   56C    P0             42W /  285W |    1247MiB /  16376MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A            1475      G   /usr/bin/kwin_wayland                    42MiB |
|    0   N/A  N/A            1555      G   /usr/bin/Xwayland                         4MiB |
|    0   N/A  N/A            1612    C+G   /usr/bin/plasmashell                    344MiB |
|    0   N/A  N/A            1831      G   /usr/lib/firefox/firefox                176MiB |
|    0   N/A  N/A            1832      G   /usr/lib/thunderbird/thunderbird        145MiB |
|    0   N/A  N/A            2194      G   /opt/tidal-hifi/tidal-hifi              179MiB |
+-----------------------------------------------------------------------------------------+

➜  ~ sort /proc/driver/nvidia/params
CoherentGPUMemoryMode: ""
CreateImexChannel0: 0
DeviceFileGID: 0
DeviceFileMode: 438
DeviceFileUID: 0
DmaRemapPeerMmio: 1
DynamicPowerManagement: 3
DynamicPowerManagementVideoMemoryThreshold: 200
EnableDbgBreakpoint: 0
EnableGpuFirmware: 18
EnableGpuFirmwareLogs: 2
EnableMSI: 1
EnablePCIeGen3: 0
EnablePCIERelaxedOrderingMode: 0
EnableResizableBar: 0
EnableS0ixPowerManagement: 0
EnableStreamMemOPs: 0
EnableSystemMemoryPools: 529
EnableUserNUMAManagement: 1
ExcludedGpus: ""
GpuBlacklist: ""
GrdmaPciTopoCheckOverride: 0
IgnoreMMIOCheck: 0
ImexChannelCount: 2048
InitializeSystemMemoryAllocations: 1
KMallocHeapMaxSize: 0
MemoryPoolSize: 0
ModifyDeviceFiles: 1
NvLinkDisable: 0
OpenRmEnableUnsupportedGpus: 1
PreserveVideoMemoryAllocations: 2
RegisterPCIDriver: 1
RegistryDwords: ""
RegistryDwordsPerDevice: ""
ResmanDebugLevel: 4294967295
RmLogonRC: 1
RmMsg: ""
RmNvlinkBandwidthLinkCount: 0
RmProfilingAdminOnly: 1
S0ixPowerManagementVideoMemoryThreshold: 256
TegraGpuPgMask: 4294967295
TemporaryFilePath: "/var/tmp"
UseKernelSuspendNotifiers: 1
UsePageAttributeTable: 4294967295
VMallocHeapMaxSize: 0

I was surprised by PreserveVideoMemoryAllocations: 2, but I think it comes from the fact that UseKernelSuspendNotifiers: 1 is its successor.

I have this modules line:

MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)

and these HOOKS:

HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block sd-encrypt filesystems fsck)

in my

➜  ~ cat /etc/mkinitcpio.conf

I have a slightly more complicated setup with LUKS and btrfs (because I want to start using snapshots soon) :

➜  ~ cat /etc/fstab          
# /dev/mapper/cryptroot LABEL=arch_btrfs
UUID=xxxxxxxxxxxxx	/         	btrfs     	rw,relatime,compress=zstd:3,ssd,space_cache=v2,subvol=/@	0 0

# /dev/mapper/cryptroot LABEL=arch_btrfs
UUID=xxxxxxxxxxxxx	/home     	btrfs     	rw,relatime,compress=zstd:3,ssd,space_cache=v2,subvol=/@home	0 0

# /dev/mapper/cryptroot LABEL=arch_btrfs
UUID=xxxxxxxxxxxxx	/games    	btrfs     	rw,relatime,compress=zstd:3,ssd,space_cache=v2,subvol=/@games	0 0

# /dev/mapper/cryptroot LABEL=arch_btrfs
UUID=xxxxxxxxxxxxx	/swap     	btrfs     	subvol=/@swap	0 0

# /dev/nvme0n1p2 LABEL=boot
UUID=jjjjjjjjjjjjjjjjjj	/boot     	ext4      	rw,relatime	0 2

# /dev/nvme0n1p3 LABEL=EFI
UUID=zzzzzzzzzzz      	/efi      	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro	0 2

/swap/swapfile      	none      	swap      	defaults  	0 0

I have a feeling this might be related somehow.

For the drm kernel mode setting I have:

➜  ~ sudo cat /sys/module/nvidia_drm/parameters/modeset
[sudo] password for xxxxxxxx: 
Y

fbdev:

➜  ~ sudo cat /sys/module/nvidia_drm/parameters/fbdev
Y

I have a KeyChron Q3 HE Keyboard, I read they can cause issues- but the suspend also doesn't work with a sleep 10 && systemctl suspend with the keyboard disconnected, so I think it is not the immediate problem.

When I suspend, the screen goes black, the computer keeps running, and I hear the fans turning. It is completely unresponsive until I press and hold the power button. Then it will boot and query for the LUKS key as normal and proceeds to boot.
Can you please help me figure this out? What logs do you need to help me?

Last edited by tranqu (2026-04-28 14:50:39)

5hridhyan · 2026-04-28 14:56:12

Please post your complete system journal for the "affected" boot:

sudo journalctl -b | curl --upload-file - 'https://paste.c-net.org/'

-b -1 for previous boot.

tranqu · 2026-04-28 15:01:27

Thank you for your help!! These are the logs. I did the test with disconnected keyboard then.
paste.c-net.org

seth · 2026-04-28 16:40:43

Journal doesn't seem to cover a sleep attempt.
When the system doesn't properly wake up, can your reboot using the https://wiki.archlinux.org/title/Keyboa … el_(SysRq) (sysrq+REISUB, nb. you'll have to explicitly enable that *before* the sleep)

You can also try https://aur.archlinux.org/packages?O=0&K=580xx and to disable the https://wiki.archlinux.org/title/NVIDIA … P_firmware (this doesn't work w/ the OSS drivers)

Why do you "mem_sleep_default=deep" ? Does it default to s2idle? Does that work?

tranqu · 2026-04-29 10:34:00

To be honest I don't remember. I think when I first installed arch I realized neither s2idle nor deep suspend worked, so I just left it at that. That was a while ago and since then I also installed other nvidia drivers.
I changed it back to s2idle and sleep works now, thank you!!! In one out of 3 sleep and wake cycles I had my graphics card freak out and have wierd artifacts and flickering screen, but it went away after Ctrl+Alt+4 and then back to Ctrl+Alt+2.
I think this is fine for now, I can press those keys in case it happens.

Now while I am there I looked into enabling/using hibernation aswell.
here in the wiki it says

When using the resume= kernel parameter, it must point to the unlocked/mapped device that contains the file system with the swap file.

So I would just add resume=<uuid_of_my_swap_partition> to my cmdline in grub?

I am a little hesistant to just put it there, I don't want to make my system unbootable.

Would I need anything else, given that luks is being used?

seth · 2026-04-29 13:58:03

The syntax is slightly different, https://wiki.archlinux.org/title/Power_ … e_location but also that's taking about a swap FILE.
For encrypted swap partitions the configuration is a bit more involved and also depends on whether you're using the systemd or busybox hooks in your mkinitcpio.conf - https://wiki.archlinux.org/title/Dm-cry … _partition

It is extremely unlikely that the system becomes unbootable for the resume parameter or hook, worst case is typically that resuming form hibernation doesn't work and you end up w/ a (dirty) reboot.
Ifffff the resume parameter (which isn't even necessary w/ the systemd hooks) was to break the boot, you could edit it away at the bootloader or at least fix the system offline from some live distro (install iso will do)

tranqu · 2026-04-29 15:15:22

Oh I see.
I think I have my swap setup as swapfile:

➜  ~ free
               total        used        free      shared  buff/cache   available
Mem:        65666608     9571968    27528628      457760    28457876    56094640
Swap:       16777212           0    16777212
➜  ~ swapon --show
NAME           TYPE SIZE USED PRIO
/swap/swapfile file  16G   0B   -1

It is not used because I have enough memory.
How big a swapfile should I create so that Hibernate can work? I have read in several places that it does not have to be as big as I have RAM- but rarely how much is enough.

My system is UEFI based.

When the system hibernates, the memory image is dumped to the swap space, which also includes the state of mounted file systems. Therefore, the hibernate location must be made available to the initramfs, i.e. before the root file system is mounted for resuming from hibernate to work.

When the system is running on UEFI, systemd-sleep(8) will automatically pick a suitable swap space to hibernate into, and the information of the used swap space is stored in HibernateLocation EFI variable. Upon next boot, systemd-hibernate-resume(8) reads the location off the EFI variable and the system resumes. This means the following steps are not necessary unless the system is using legacy BIOS or you want to choose a different swap space from the automatically-selected one.

So it should be able to work kind of by itself. How would you recommend I troubleshoot this? Again start with the journalctl with a stuck hibernation attempt?

seth · 2026-04-29 15:44:28

How big a swapfile should I create so that Hibernate can work? I have read in several places that it does not have to be as big as I have RAM- but rarely how much is enough.

https://wiki.archlinux.org/title/Power_ … /file_size

Reading from it returns the current image size limit, which is set to around 2/5 of the available RAM size by default.

So it should be able to work kind of by itself.

I'm not sure this works w/ the busybox hooks or dm-crypt

start with the journalctl with a stuck hibernation attempt?

Yup.

tranqu · 2026-04-29 19:08:40

I recreated my swapfile:

➜  ~ sudo swapoff /swap/swapfile 
➜  ~ sudo rm -f /swap/swapfile
➜  ~ sudo mkswap -U clear --size 26G --file /swap/swapfile
Setting up swapspace version 1, size = 26 GiB (27917283328 bytes)
no label, UUID=00000000-0000-0000-0000-000000000000
➜  ~ sudo swapon /swap/swapfile
➜  ~ free
               total        used        free      shared  buff/cache   available
Mem:        65666616     7850096    41180100      432500    17008640    57816520
Swap:       27262972           0    27262972
➜  ~ swapon --show
NAME           TYPE SIZE USED PRIO
/swap/swapfile file  26G   0B   -1
➜  ~ cat /sys/power/image_size 
26774482944

27917283328(bytes)−26774482944(bytes) should be 1142800384 left, so I think the swapfile should be big enough.

So from my understanding I am using a systemd based initramfs:

➜  ~ cat /etc/mkinitcpio.conf     (removed the commented out stuff/examples) 
MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)
HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block sd-encrypt filesystems fsck)

because the 2nd hook is systemd.
In the wiki here
it says

Using a swap file
A swap file can be placed in a file system within an encrypted device. Follow the swap file creation instructions in Swap#Swap file and set up hibernation according to Power management/Suspend and hibernate#Configure the initramfs.
When used with a systemd-based initramfs and an encrypted root filesystem, this can be a very simple and flexible method for encrypting swap. After setting up an encrypted root filesystem, the swap file can be made, activated, and added to /etc/fstab and work for hibernation without any further setup.

the linked part in Power Management/Suspend and hibernate #Configure the initramfs says

Configure the initramfs
When the default systemd-based initramfs (using the systemd hook) is used, a resume mechanism is already provided and no further hooks are required.

So it reads to me as if as long as I have the swapfile created and added to fstab, hibernation should work. Or am I making a wrong conclusion here from what I read and have configured?
(will now reproduce and add the journalcrl logs after posting this)

tranqu · 2026-04-29 19:33:58

So this is before the hibernation:
https://paste.c-net.org/SandboxPelican
and this is after:
https://paste.c-net.org/CravingBathing

The system booted fine(which it usually didn't, as it got stuck when going into hibernate), I think increasing the swapfile size might have helped already.
But it was an attempted and failed resume.

Apr 29 21:10:39 archlinux systemd[1]: Found device /dev/disk/by-uuid/773d60d6-98f4-41de-9847-50d25e257fb7.
Apr 29 21:10:39 archlinux systemd[1]: Finished Cryptography Setup for cryptroot.
Apr 29 21:10:39 archlinux systemd[1]: Reached target Local Encrypted Volumes.
Apr 29 21:10:39 archlinux systemd[1]: Reached target Initrd Root Device.
Apr 29 21:10:39 archlinux systemd[1]: Starting Resume from hibernation...
Apr 29 21:10:39 archlinux systemd-hibernate-resume[637]: Reported hibernation image: ID=arch kernel=6.19.14-arch1-1 UUID=773d60d6-98f4-41de-9847-50d25e257fb7 offset=20319361
Apr 29 21:10:39 archlinux kernel: PM: Image signature found, resuming
Apr 29 21:10:39 archlinux kernel: PM: hibernation: resume from hibernation
Apr 29 21:10:39 archlinux kernel: random: crng reseeded on system resumption
Apr 29 21:10:51 archlinux kernel: Freezing user space processes
Apr 29 21:10:51 archlinux kernel: Freezing user space processes completed (elapsed 0.001 seconds)
Apr 29 21:10:51 archlinux kernel: OOM killer disabled.
Apr 29 21:10:51 archlinux kernel: Freezing remaining freezable tasks
Apr 29 21:10:51 archlinux kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
Apr 29 21:10:51 archlinux kernel: PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]
Apr 29 21:10:51 archlinux kernel: PM: hibernation: Marking nosave pages: [mem 0x0009e000-0x0009efff]
Apr 29 21:10:51 archlinux kernel: PM: hibernation: Marking nosave pages: [mem 0x000a0000-0x000fffff]
Apr 29 21:10:51 archlinux kernel: PM: hibernation: Marking nosave pages: [mem 0x316fd000-0x3177bfff]
Apr 29 21:10:51 archlinux kernel: PM: hibernation: Marking nosave pages: [mem 0x33f8e000-0x33f8efff]
Apr 29 21:10:51 archlinux kernel: PM: hibernation: Marking nosave pages: [mem 0x35a98000-0x39bfefff]
Apr 29 21:10:51 archlinux kernel: PM: hibernation: Marking nosave pages: [mem 0x39c00000-0xffffffff]
Apr 29 21:10:51 archlinux kernel: PM: hibernation: Basic memory bitmaps created
Apr 29 21:10:51 archlinux kernel: PM: Using 3 thread(s) for lzo decompression
Apr 29 21:10:51 archlinux kernel: PM: Loading and decompressing image data (5643759 pages)...
Apr 29 21:10:51 archlinux kernel: PM: Image loading progress: 0%
Apr 29 21:10:51 archlinux kernel: PM: Image loading progress: 10%
Apr 29 21:10:51 archlinux kernel: PM: Image loading progress: 20%
Apr 29 21:10:51 archlinux kernel: PM: Image loading progress: 30%
Apr 29 21:10:51 archlinux kernel: PM: Image loading progress: 40%
Apr 29 21:10:51 archlinux kernel: PM: Image loading progress: 50%
Apr 29 21:10:51 archlinux kernel: PM: Image loading progress: 60%
Apr 29 21:10:51 archlinux kernel: PM: Image loading progress: 70%
Apr 29 21:10:51 archlinux kernel: PM: Image loading progress: 80%
Apr 29 21:10:51 archlinux kernel: PM: Image loading progress: 90%
Apr 29 21:10:51 archlinux kernel: PM: Image loading progress: 100%
Apr 29 21:10:51 archlinux kernel: PM: Image loading done
Apr 29 21:10:51 archlinux kernel: PM: hibernation: Read 22575036 kbytes in 10.45 seconds (2160.29 MB/s)
Apr 29 21:10:51 archlinux kernel: PM: Image successfully loaded
Apr 29 21:10:51 archlinux kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Apr 29 21:10:51 archlinux kernel: serial 00:01: disabled
Apr 29 21:10:51 archlinux kernel: NVRM: GPU 0000:01:00.0: PreserveVideoMemoryAllocations module parameter is set. System Power Management attempted without driver procfs suspend interface. Please refer to the 'Configuring Power Management Support' section in the driver README.
Apr 29 21:10:51 archlinux kernel: nvidia 0000:01:00.0: PM: pci_pm_freeze(): nv_pmops_freeze [nvidia] returns -5
Apr 29 21:10:51 archlinux kernel: nvidia 0000:01:00.0: PM: dpm_run_callback(): pci_pm_freeze returns -5
Apr 29 21:10:51 archlinux kernel: nvidia 0000:01:00.0: PM: failed to quiesce async: error -5

This is great to me because it seems the swapfile where the image was written to could be found and read, but then fails because of the graphics card.

It said here in this issue:
https://github.com/NVIDIA/open-gpu-kern … issues/472

Keep the swap size at least equal or greater than your system memory + gpu memory

Maybe the issue is the swapfile size, as my 4070Ti has ~16Gb of vram? I feel like the error would be more about the size then, but what do I know.
Should I first try to increase the swapfile size again, or does it sound more related to the nvidia config to you?
Like as if I should first fully remove that "NVreg_PreserveVideoMemoryAllocations" module parameter, no idea where that might be set.

seth · 2026-04-29 20:00:07

You need to move the nvidia drivers out of the initramfs, https://bbs.archlinux.org/viewtopic.php?id=285508

tranqu · 2026-04-30 00:15:00

I removed the drivers out of the initramfs, so all of these

MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)

and turned the line into MODULES=()
I left the entry in grub in the CMDLINE_LINUX nvidia_drm.modeset=1

Unfortunately, I am now without Image on my main monitor on boot. That one is connected via DP and has 5120x1440 resolution.
I can connect another screen via hdmi, it has lower res(2550x1440) and on that monitor I can see the LUKS Passphrase query and rest of the startup.
When logged in to KDE I can plug in my other monitor and unplug the smaller one.

Do you have an idea how to get the image back at that point?

Hah, just noticed that when I type my passphrase right the booting continues blind and then at some point plasma greeter starts up and the monitor turns back on.
Nice kind of tampering protection maybe.

Last edited by tranqu (2026-04-30 00:19:43)

seth · 2026-04-30 06:21:54

1. does it fix your hibernation problems?
2. you can try to enforce a lower resolution, https://www.kernel.org/doc/Documentation/fb/modedb.rst

Edit: for clarification, you're swapping the monitors on the same HDMI port? You're not attaching one to the GPU and the other one to an IGP?

Last edited by seth (2026-04-30 06:22:45)

tranqu · 2026-04-30 07:17:23

Good Morning!
Yes it seems that it fixed the hibernation. And suspend with s2idle does work aswell. So big thank you for that already!!

I was not swapping- the smaller monitor I had connected with lower res and that works to show the luks query. The other monitor i left unplugged because it got no signal. when the plasma-greeter was shown I plugged the 2nd screen in and unplugged the first.
But this session again I just typed the passphrase in blind on a black second screen and again the monitor gets a signal when booting is finished and plasma-greeter presented.

seth · 2026-04-30 12:47:58

What if you switch the monitors (attach one to the output where the other currently sits and vv)?

tranqu · 2026-04-30 13:17:46

The small one does not have a Displayport Socket and I would not have a long enough cable. The small Monitor is on another desk in my office and usually used.
I will try to play with forcing a lower resolution first, have to read through all that, as it looks a little complicated and I don't have much spare time today.
Will come back here when I have learnt something new.

Arch Linux

#1 2026-04-28 14:50:03

Unresponsive Black Screen after suspend

#2 2026-04-28 14:56:12

Re: Unresponsive Black Screen after suspend

#3 2026-04-28 15:01:27

Re: Unresponsive Black Screen after suspend

#4 2026-04-28 16:40:43

Re: Unresponsive Black Screen after suspend

#5 2026-04-29 10:34:00

Re: Unresponsive Black Screen after suspend

#6 2026-04-29 13:58:03

Re: Unresponsive Black Screen after suspend

#7 2026-04-29 15:15:22

Re: Unresponsive Black Screen after suspend

#8 2026-04-29 15:44:28

Re: Unresponsive Black Screen after suspend

#9 2026-04-29 19:08:40

Re: Unresponsive Black Screen after suspend

#10 2026-04-29 19:33:58

Re: Unresponsive Black Screen after suspend

#11 2026-04-29 20:00:07

Re: Unresponsive Black Screen after suspend

#12 2026-04-30 00:15:00

Re: Unresponsive Black Screen after suspend

#13 2026-04-30 06:21:54

Re: Unresponsive Black Screen after suspend

#14 2026-04-30 07:17:23

Re: Unresponsive Black Screen after suspend

#15 2026-04-30 12:47:58

Re: Unresponsive Black Screen after suspend

#16 2026-04-30 13:17:46

Re: Unresponsive Black Screen after suspend

Board footer