Suspend fails after recent updates

vasocreta · November 10, 2025, 5:09am

Hello,

Requirements:

[x]

I have Searched the forum for my issue and found nothing related or helpful
I have checked the Resources category (Resources Index)
I have reviewed the Wiki for relevant information
I have read the the Release Notes and Errata

OpenMandriva Lx version:

OpenMandriva Lx release 25.11 (ROME) Rolling for znver1

Desktop environment (KDE, LXQT…):

KDE

Description of the issue (screenshots if relevant):

Following a recent system update, Sleep (Suspend) has been failing. The GPU appears to suspend, but the rest of the hardware does not. Fans continue to spin, lights remain on, etc. However, all video output ceases. The only way to resume the gpu is via a hard reboot. Output of journalctl | grep suspend is attached. It is possible that this is a bug in kernel 6.17.7, but I have not been able to confirm that yet.

Relevant informations (hardware involved, software version, logs or output…):

Nov 09 13:26:19 vasocreta-PC systemd-logind[1004]: The system will suspend now!
Nov 09 13:26:19 vasocreta-PC systemd[1]: Starting systemd-suspend.service - System Suspend...
Nov 09 13:26:19 vasocreta-PC systemd-sleep[5364]: Performing sleep operation 'suspend'...
Nov 09 13:26:19 vasocreta-PC kernel: PM: suspend entry (deep)
Nov 09 13:26:44 vasocreta-PC kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Nov 09 13:26:44 vasocreta-PC kernel: queueing ieee80211 work while going to suspend
Nov 09 13:26:44 vasocreta-PC kernel: amdgpu 0000:2d:00.0: PM: pci_pm_suspend_noirq(): amdgpu_pmops_suspend_noirq [amdgpu] returns -62
Nov 09 13:26:44 vasocreta-PC kernel: amdgpu 0000:2d:00.0: PM: dpm_run_callback(): pci_pm_suspend_noirq.llvm.9934536577301451047 returns -62
Nov 09 13:26:44 vasocreta-PC kernel: amdgpu 0000:2d:00.0: PM: failed to suspend async noirq: error -62
Nov 09 13:26:44 vasocreta-PC kernel: PM: noirq suspend of devices failed
Nov 09 13:26:44 vasocreta-PC kernel: PM: suspend exit
Nov 09 13:26:44 vasocreta-PC kernel: PM: suspend entry (s2idle)
Nov 09 13:26:45 vasocreta-PC kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Nov 09 13:26:45 vasocreta-PC kernel: queueing ieee80211 work while going to suspend
Nov 09 13:26:45 vasocreta-PC kernel: xhci_hcd 0000:02:00.0: PM: pci_pm_suspend(): hcd_pci_suspend [usbcore] returns -16
Nov 09 13:26:45 vasocreta-PC kernel: xhci_hcd 0000:02:00.0: PM: dpm_run_callback(): pci_pm_suspend.llvm.9934536577301451047 returns -16
Nov 09 13:26:45 vasocreta-PC kernel: xhci_hcd 0000:02:00.0: PM: failed to suspend async: error -16
Nov 09 13:26:45 vasocreta-PC kernel: PM: Some devices failed to suspend, or early wake event detected
Nov 09 13:26:45 vasocreta-PC kernel: PM: suspend exit
Nov 09 13:26:45 vasocreta-PC systemd[1]: systemd-suspend.service: Main process exited, code=exited, status=1/FAILURE
Nov 09 13:26:45 vasocreta-PC systemd[1]: systemd-suspend.service: Failed with result 'exit-code'.
Nov 09 13:26:45 vasocreta-PC systemd[1]: Failed to start systemd-suspend.service - System Suspend.
Nov 09 13:26:45 vasocreta-PC systemd[1]: Dependency failed for suspend.target - Suspend.
Nov 09 13:26:45 vasocreta-PC systemd[1]: suspend.target: Job suspend.target/start failed with result 'dependency'.
Nov 09 13:26:45 vasocreta-PC systemd-logind[1004]: Operation 'suspend' finished.
Nov 09 13:26:56 vasocreta-PC kernel:  gfx_v10_0_suspend.llvm.657283598817689693+0x9/0x20 [amdgpu]
Nov 09 13:26:56 vasocreta-PC kernel:  amdgpu_device_ip_suspend_phase2+0x142/0x1d0 [amdgpu]
Nov 09 13:26:56 vasocreta-PC kernel:  amdgpu_device_ip_suspend+0x48/0x70 [amdgpu]
Nov 09 13:26:56 vasocreta-PC kernel:  gfx_v10_0_suspend.llvm.657283598817689693+0x9/0x20 [amdgpu]
Nov 09 13:26:56 vasocreta-PC kernel:  amdgpu_device_ip_suspend_phase2+0x142/0x1d0 [amdgpu]
Nov 09 13:26:56 vasocreta-PC kernel:  amdgpu_device_ip_suspend+0x48/0x70 [amdgpu]
Nov 09 13:26:57 vasocreta-PC kernel:  gfx_v10_0_suspend.llvm.657283598817689693+0x9/0x20 [amdgpu]
Nov 09 13:26:57 vasocreta-PC kernel:  amdgpu_device_ip_suspend_phase2+0x142/0x1d0 [amdgpu]
Nov 09 13:26:57 vasocreta-PC kernel:  amdgpu_device_ip_suspend+0x48/0x70 [amdgpu]
Nov 09 13:26:57 vasocreta-PC kernel:  smu_suspend.llvm.804340094443634798+0x58/0xf0 [amdgpu]
Nov 09 13:26:57 vasocreta-PC kernel:  amdgpu_device_ip_suspend_phase2+0x142/0x1d0 [amdgpu]
Nov 09 13:26:57 vasocreta-PC kernel:  amdgpu_device_ip_suspend+0x48/0x70 [amdgpu]
Nov 09 13:26:57 vasocreta-PC kernel: amdgpu 0000:2d:00.0: amdgpu: suspend of IP block <smu> failed -22
Nov 09 13:26:58 vasocreta-PC kernel: amdgpu 0000:2d:00.0: amdgpu: suspend of IP block <psp> failed -22
Nov 09 13:26:58 vasocreta-PC kernel:  gmc_v10_0_suspend.llvm.9395723195317780771+0x9/0x20 [amdgpu]
Nov 09 13:26:58 vasocreta-PC kernel:  amdgpu_device_ip_suspend_phase2+0x142/0x1d0 [amdgpu]
Nov 09 13:26:58 vasocreta-PC kernel:  amdgpu_device_ip_suspend+0x48/0x70 [amdgpu]

zeroability · November 10, 2025, 11:54am

Make sure you are doing that. Especially for updates.

@bero would probably know about that, if it is. A fix should be coming, if so.

schappellshow · November 10, 2025, 12:12pm

I had this issue pop up before the new update (while using kernel 6.14.2). For me, if I manually locked my screen “CTRL + L” and then chose “Sleep” from the lock screen menu, my monitors would shut off, but all the fans in my PC would continue to run. I found, though, that if I just leave my computer to go to sleep on its own, that it reliably works every time. That’s why I haven’t posted about it.

So, in the situation that you mentioned, did you let your computer sleep on its own? Or did you manually choose to put it to sleep?

vasocreta · November 10, 2025, 2:38pm

I did read the Release Notes and Errata but the box won’t stay checked when I actually click on it. I think it might be a browser issue.

stephane · November 10, 2025, 6:44pm

wait next version kernel coming

see Making sure you're not a bot!

for patches drm amdgpu display

vasocreta · November 10, 2025, 8:17pm

Excellent! Thanks.

sez11a · November 17, 2025, 9:06pm

Having the same issue, but I could work around it by clicking Sleep from the Kickoff menu or by issuing systemctl suspend. Now, however, my wife is having the same issue, so I have to fix it.

I spent time with Grok today trying to troubleshoot it. It seemed strange to me that suspend worked from the CLI or when selected from the menu, but not when I shut the lid. Here’s some of what Grok says, and the ways of resolving it. I kind of want to run this by humans before implementing anything.

First, this is what happens when I try to suspend via the lid:

journalctl -b | grep -i "suspend" | tail -20
Nov 17 15:45:25 wanderer systemd[1]: Starting systemd-suspend.service - System Suspend...
Nov 17 15:45:25 wanderer systemd-sleep[29269]: Performing sleep operation 'suspend'...
Nov 17 15:45:25 wanderer kernel: PM: suspend entry (deep)
Nov 17 15:45:26 wanderer kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Nov 17 15:45:26 wanderer kernel: PM: Some devices failed to suspend, or early wake event detected
Nov 17 15:45:26 wanderer kernel: amdgpu 0000:07:00.0: amdgpu: S3 suspend abort case, let's reset ASIC.
Nov 17 15:45:27 wanderer kernel: PM: suspend exit
Nov 17 15:45:27 wanderer kernel: PM: suspend entry (s2idle)
Nov 17 15:45:33 wanderer kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Nov 17 15:45:33 wanderer kernel: amdgpu 0000:07:00.0: PM: pci_pm_suspend(): amdgpu_pmops_suspend [amdgpu] returns -22
Nov 17 15:45:33 wanderer kernel: amdgpu 0000:07:00.0: PM: dpm_run_callback(): pci_pm_suspend.llvm.9934536577301451047 returns -22
Nov 17 15:45:33 wanderer kernel: amdgpu 0000:07:00.0: PM: failed to suspend async: error -22
Nov 17 15:45:33 wanderer kernel: PM: Some devices failed to suspend, or early wake event detected
Nov 17 15:45:33 wanderer kernel: PM: suspend exit
Nov 17 15:45:33 wanderer systemd[1]: systemd-suspend.service: Main process exited, code=exited, status=1/FAILURE
Nov 17 15:45:33 wanderer systemd[1]: systemd-suspend.service: Failed with result 'exit-code'.
Nov 17 15:45:33 wanderer systemd[1]: Failed to start systemd-suspend.service - System Suspend.
Nov 17 15:45:33 wanderer systemd[1]: Dependency failed for suspend.target - Suspend.
Nov 17 15:45:33 wanderer systemd[1]: suspend.target: Job suspend.target/start failed with result 'dependency'.
Nov 17 15:45:33 wanderer systemd-logind[27571]: Operation 'suspend' finished.

Here’s what Grok says about it:

What’s really happening

When you run systemctl suspend manually → it works because the AMD GPU is idle and in a “runtime-suspended” state already. The driver can suspend cleanly.

When you close the lid → KDE/PowerDevil does not wait for the GPU to go into runtime suspend first. It triggers the system suspend almost instantly while the AMD iGPU is still active (rendering the screen-off black frame, KWin compositing, etc.).
The amdgpu driver sees it’s still busy and aborts the suspend with -EINVAL (-22).
You see the “S3 suspend abort case → reset ASIC” and then it falls back to s2idle, which also fails for the same reason.

This is a very well-known regression on AMD Phoenix (Ryzen 7040) and Hawk Point (Ryzen 8040) in kernels 6.10–6.12 when using KDE/Wayland (X11 is sometimes less affected). It hits ThinkPad P14s Gen 4/5 AMD the hardest.

It then recommends three possible fixes:

#1:

In KDE System Settings → Power Management → Energy Saving → “When laptop lid closed”
Change the action from “Suspend session” to “Run script” and use this one-liner:
sleep 3 && systemctl suspend

#2:

Add this kernel parameter (OpenMandriva uses dracut):
sudo mkdir -p /etc/dracut.conf.d
echo 'add_dracutmodules+=" amdgpu-suspend "' | sudo tee /etc/dracut.conf.d/amdgpu-suspend.conf
sudo dracut -f
Then reboot and add the parameter amdgpu.dcdebugmask=0x40 or simply:
sudo kernelcmdline-add "amdgpu.suspend=1"
(or manually add amdgpu.suspend=1 to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, then sudo grub2-mkconfig -o /boot/grub2/grub.cfg)This forces the driver to be more aggressive about runtime PM before system suspend — fixes it for lid close, manual suspend, everything.

#3:

Keep KDE set to “Suspend session” and create this drop-in that delays only the lid-triggered suspend:
sudo mkdir -p /etc/systemd/system/systemd-logind.service.d
sudo tee /etc/systemd/system/systemd-logind.service.d/lid-delay.conf <<EOF
[Service]
Environment=SYSTEMD_LOGIND_LID_CLOSE_DELAY=3
EOF
(No longer needed in newer systemd, but still works on OpenMandriva’s version.)I personally run Fix 1 (the “sleep 3 && systemctl suspend” script) on my own P14s Gen 4 AMD with OpenMandriva — zero failed suspends since I switched to it.

I am particularly amused that Grok believes it owns and runs a P14S Thinkpad with AMD and OpenMandriva, but maybe that’s because I told it once that OpenMandriva is non-woke.

Regardless, do any of these three solutions sound like good long-term steps, or is it better to wait for the next kernel release as stated above?

vasocreta · November 24, 2025, 2:28pm

I have tried both ways: manual initiation of Sleep and just letting the machine go into Sleep on its own.
Both yield the same result.

vasocreta · November 24, 2025, 6:31pm

Nov 24 11:11:14 vasocreta-PC systemd-logind[1011]: The system will suspend now!
Nov 24 11:11:14 vasocreta-PC systemd[1]: Starting systemd-suspend.service - System Suspend…
Nov 24 11:11:14 vasocreta-PC systemd-sleep[4861]: Performing sleep operation ‘suspend’…
Nov 24 11:11:14 vasocreta-PC kernel: PM: suspend entry (deep)
[vasocreta@vasocreta-PC ~]$ uname -r
6.18.0-desktop-0.rc4.2omv259

As an update, I did try installing the RC kernel.
Strangely, the journalctl output is DIFFERENT than before, suggesting that everything works as intended, but the hardware behavior is still the same: video output stops, but the rest of the machines remains running. A hardboot continues to be the only way to get back into the OS.

This makes me wonder if there is a GPU driver or even BIOS issue. But it seems I will have to wait until the RC kernel version is stabilized before I go down other avenues.