Hi,
After reinstalling Fedora 41 on my laptop (AMD Ryzen 7 7840), I encountered an issue. The laptop takes 35 to 45 seconds to resume from suspend, regardless of whether I simply closed the lid or manually triggered suspend. During this time, the screen remains black.
Does anyone have any suggestions on how to fix this? I didn’t have this issue before the reinstall.
System:
Fedora 41
Kernel: 6.12.7
Firmware: 03.05
Thanks in advance! 
Is there any difference when suspending from a different tty w/o a display server running?
Great suggestion! I tried both closing the lid and using systemctl suspend after logging in via Ctrl + Alt + F2, but there is no difference.
As I understand you the issue wasn’t there before reinstallation of Fedora, so it does not seem to be a hardware fault.
Is there any delay configured in logind conf, e.g. /etc/systemd/logind.conf or /etc/systemd/logind.conf.d/*?
You’re right, I don’t think it’s a hardware issue. The only logind.conf file I have is located in /usr/lib/systemd/ and its contents are as follows:
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it under the
# terms of the GNU Lesser General Public License as published by the Free
# Software Foundation; either version 2.1 of the License, or (at your option)
# any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file (or a copy of it placed in
# /etc/ if the original file is shipped in /usr/), or by creating "drop-ins" in
# the /etc/systemd/logind.conf.d/ directory. The latter is generally
# recommended. Defaults can be restored by simply deleting the main
# configuration file and all drop-ins located in /etc/.
#
# Use 'systemd-analyze cat-config systemd/logind.conf' to display the full config.
#
# See logind.conf(5) for details.
[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#UserStopDelaySec=10
#SleepOperation=suspend-then-hibernate suspend
#HandlePowerKey=poweroff
#HandlePowerKeyLongPress=ignore
#HandleRebootKey=reboot
#HandleRebootKeyLongPress=poweroff
#HandleSuspendKey=suspend
#HandleSuspendKeyLongPress=hibernate
#HandleHibernateKey=hibernate
#HandleHibernateKeyLongPress=ignore
#HandleLidSwitch=suspend
#HandleLidSwitchExternalPower=suspend
#HandleLidSwitchDocked=ignore
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#RebootKeyIgnoreInhibited=no
#HoldoffTimeoutSec=30s
#IdleAction=ignore
#IdleActionSec=30min
#RuntimeDirectorySize=10%
#RuntimeDirectoryInodesMax=
#RemoveIPC=yes
#InhibitorsMax=8192
#SessionsMax=8192
#StopIdleSessionSec=infinity
It should be the default configuration as I didn’t do any custom changes…
Is it possible that your system actually hibernates?
Some people are having suspend issues (me also) that result in their FW13 7040 rebooting instead of waking up from suspend. Hibernation, on the other hand, works. Since the default SleepOperation in your distribution seems to be suspend-then-hibernate, you laptop might actually wake up from hibernation due to a failed suspend, which then takes some time.
@chwd I would also ask if it is happening with any external devices connected? Did you restore any backups when you reinstalled the OS? Could you see if it happens from a live disk as well? A live disk would be the media that you used to install Fedora.
Hi,
The boot time doesn’t change with external devices connected, and even when booting from a Fedora 41 Live USB stick, it takes a long time for the computer to wake up.
Thanks!
You might be right! I just checked the logs with journalctl | grep -i suspend after waking up the PC, and here’s the output:
Jan 07 16:36:40 xcv systemd-logind[1601]: The system will suspend now!
Jan 07 16:36:40 xcv ModemManager[1688]: <msg> [sleep-monitor-systemd] system is about to suspend
Jan 07 16:36:41 xcv systemd[1]: Starting systemd-suspend.service - System Suspend...
Jan 07 16:36:41 xcv systemd-sleep[5979]: in suspend-then-hibernate operations or setups with encrypted home directories.
Jan 07 16:36:41 xcv systemd-sleep[5979]: Performing sleep operation 'suspend'...
Jan 07 16:36:41 xcv kernel: PM: suspend entry (s2idle)
Jan 07 16:37:21 xcv kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Jan 07 16:37:21 xcv kernel: queueing ieee80211 work while going to suspend
Jan 07 16:37:21 xcv kernel: PM: suspend devices took 0.115 seconds
Jan 07 16:37:21 xcv kernel: PM: suspend exit
Jan 07 16:37:21 xcv systemd-sleep[5979]: System returned from sleep operation 'suspend'.
Jan 07 16:37:21 xcv systemd[1]: systemd-suspend.service: Deactivated successfully.
Jan 07 16:37:21 xcv systemd[1]: Finished systemd-suspend.service - System Suspend.
Jan 07 16:37:21 xcv audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jan 07 16:37:21 xcv audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jan 07 16:37:21 xcv systemd[1]: Reached target suspend.target - Suspend.
Jan 07 16:37:21 xcv systemd[1]: Stopped target suspend.target - Suspend.
Jan 07 16:37:21 xcv systemd-logind[1601]: Operation 'suspend' finished.
The system resumes normally without requiring me to re-enter the LUKS password, and all programs are still open when it wakes up.
Thanks for the help!
I would only expect to need to reenter the LUKS passphase unless the system was hibernating instead of suspending though…
Well, it’s definitely not doing that. Since nobody else seems to have that particular problem, I really considered reinstalling the OS, but as the device shows the same behavior when booted from a live USB, I don’t have much hope that it will change anything…
Please post the full dmesg log to somewhere like pastebin.com and put a link here. Also which devices do you have plugged in?
I have one usb device that causes some boots to be slow if plugged in during boot.
Hi,
You can find the log here: dmesg log - Pastebin.com
In the meantime, I had tried adding the boot parameter resume=UUID=... acpi_sleep=nonvs, but it didn’t make any difference – I have since reverted this change.
I’ve tried with and without connected devices and even with no expansion cards whatsoever, there was no difference with the wakeup time.
The resume problem is caused by the NVME SSD.
I see you have a SN850 disk - WDS200T1X0E-00AFY0.
Is there any updated firmware for it available from the manufacturer’s web site?
You can update the firmware from linux.
I don’t think you need the following in your kernel command line: “acpi=force acpi_osi=Linux”
Other people have seen similar problems:
I remember that I updated the firmware when I got the laptop, it now runs version 615400WD. I could not find any newer versions yet.
The script at GitHub - bkw777/wd_nvme_update: Updates the firmware of Western Digital NVME SSDs on Linux can’t find any newer versions either.
Ok, it looks like you already have the latest firmware.
The lines from the log that point me towards the nvme SSD problem are, just when trying to wake:
[ 83.229703] nvme 0000:02:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000e address=0x58e5e000 flags=0x0000]
[ 83.261982] nvme nvme0: resetting controller due to persistent internal error
It might be worth trying the “amd_s2idle.py” script, to see if that highlights anything else.
Please can you pastebin a dmesg from when you removed nonvs
Pastebin apparently blocked me after I tried to post the output of amd_s2idle.py. 
So I’m just posting it here: Hastebin (Output of sudo python3 ~/amd-master/scripts/amd_s2idle.py)
