Fedora won't wake up from suspended state

I’ve been having issues with Fedora sometimes not waking up from sleep. I have to cut the power and boot it up again. Screen remains black and I can’t even switch to different tty.
Most of the time, it wakes up fine, but sometimes, it doesn’t.

I was concerned that nvidia might be the culprit, but even if I turn the card off in bios, it doesn’t seem to help.

This issue started ever since the 6.0 kernel came out. I’m using 5.15 LTS without any issues, but was hoping to move to 6.0 eventually, when they fix the issue, but it’s been quite a while and it’s still happening.

There seems to be nothing in the logs. But here’s the full log of the issue anyway.

May 27 00:34:20 aerie systemd-logind[1588]: The system will suspend now!
May 27 00:34:20 aerie NetworkManager[1860]: <info>  [1716766460.5040] manager: sleep: sleep requested (sleeping: no  enabled: yes)
May 27 00:34:20 aerie ModemManager[1828]: <info>  [sleep-monitor-systemd] system is about to suspend
May 27 00:34:20 aerie NetworkManager[1860]: <info>  [1716766460.5048] device (enp4s0): state change: unavailable -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
May 27 00:34:20 aerie NetworkManager[1860]: <info>  [1716766460.5136] device (p2p-dev-wlp3s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
May 27 00:34:20 aerie NetworkManager[1860]: <info>  [1716766460.5138] manager: NetworkManager state is now ASLEEP
May 27 00:34:20 aerie NetworkManager[1860]: <info>  [1716766460.5139] device (wlp3s0): state change: activated -> deactivating (reason 'sleeping', sys-iface-state: 'managed')
May 27 00:34:20 aerie systemd[1]: Starting NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service...
May 27 00:34:20 aerie audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostna>
May 27 00:34:20 aerie systemd[1]: Started NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service.
May 27 00:34:20 aerie kernel: wlp3s0: deauthenticating from 52:42:89:7e:b4:2c by local choice (Reason: 3=DEAUTH_LEAVING)
May 27 00:34:20 aerie wpa_supplicant[1918]: wlp3s0: CTRL-EVENT-DISCONNECTED bssid=52:42:89:7e:b4:2c reason=3 locally_generated=1
May 27 00:34:20 aerie wpa_supplicant[1918]: wlp3s0: CTRL-EVENT-DSCP-POLICY clear_all
May 27 00:34:20 aerie NetworkManager[1860]: <info>  [1716766460.5705] device (wlp3s0): supplicant interface state: completed -> disconnected
May 27 00:34:20 aerie avahi-daemon[1542]: Withdrawing address record for fd00::6f05:3a7d:df98:b863 on wlp3s0.
May 27 00:34:20 aerie NetworkManager[1860]: <info>  [1716766460.5707] device (wlp3s0): state change: deactivating -> disconnected (reason 'sleeping', sys-iface-state: 'managed')
May 27 00:34:20 aerie wpa_supplicant[1918]: wlp3s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
May 27 00:34:20 aerie NetworkManager[1860]: <info>  [1716766460.5746] dhcp4 (wlp3s0): canceled DHCP transaction
May 27 00:34:20 aerie wpa_supplicant[1918]: wlp3s0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=GB
May 27 00:34:20 aerie NetworkManager[1860]: <info>  [1716766460.5746] dhcp4 (wlp3s0): activation: beginning transaction (timeout in 45 seconds)
May 27 00:34:20 aerie avahi-daemon[1542]: Withdrawing address record for 2a01:4b00:f03e:7e00:a038:1d55:7231:f6d1 on wlp3s0.
May 27 00:34:20 aerie NetworkManager[1860]: <info>  [1716766460.5746] dhcp4 (wlp3s0): state changed no lease
May 27 00:34:20 aerie avahi-daemon[1542]: Leaving mDNS multicast group on interface wlp3s0.IPv6 with address 2a01:4b00:f03e:7e00:a038:1d55:7231:f6d1.
May 27 00:34:20 aerie NetworkManager[1860]: <info>  [1716766460.5748] dhcp6 (wlp3s0): canceled DHCP transaction
May 27 00:34:20 aerie NetworkManager[1860]: <info>  [1716766460.5748] dhcp6 (wlp3s0): activation: beginning transaction (timeout in 45 seconds)
May 27 00:34:20 aerie NetworkManager[1860]: <info>  [1716766460.5748] dhcp6 (wlp3s0): state changed no lease
May 27 00:34:20 aerie avahi-daemon[1542]: Joining mDNS multicast group on interface wlp3s0.IPv6 with address fe80::8fc2:1129:14d1:51e7.
May 27 00:34:20 aerie NetworkManager[1860]: <info>  [1716766460.5874] device (wlp3s0): set-hw-addr: set MAC address to 9E:03:86:96:B7:59 (scanning)
May 27 00:34:20 aerie avahi-daemon[1542]: Registering new address record for fe80::8fc2:1129:14d1:51e7 on wlp3s0.*.
May 27 00:34:20 aerie avahi-daemon[1542]: Withdrawing address record for fe80::8fc2:1129:14d1:51e7 on wlp3s0.
May 27 00:34:20 aerie avahi-daemon[1542]: Leaving mDNS multicast group on interface wlp3s0.IPv6 with address fe80::8fc2:1129:14d1:51e7.
May 27 00:34:20 aerie avahi-daemon[1542]: Interface wlp3s0.IPv6 no longer relevant for mDNS.
May 27 00:34:20 aerie avahi-daemon[1542]: Interface wlp3s0.IPv4 no longer relevant for mDNS.
May 27 00:34:20 aerie avahi-daemon[1542]: Leaving mDNS multicast group on interface wlp3s0.IPv4 with address 192.168.1.206.
May 27 00:34:20 aerie avahi-daemon[1542]: Withdrawing address record for 192.168.1.206 on wlp3s0.
May 27 00:34:20 aerie avahi-daemon[1542]: Joining mDNS multicast group on interface wlp3s0.IPv4 with address 192.168.1.206.
May 27 00:34:20 aerie avahi-daemon[1542]: New relevant interface wlp3s0.IPv4 for mDNS.
May 27 00:34:20 aerie avahi-daemon[1542]: Registering new address record for 192.168.1.206 on wlp3s0.IPv4.
May 27 00:34:20 aerie avahi-daemon[1542]: Withdrawing address record for 192.168.1.206 on wlp3s0.
May 27 00:34:20 aerie avahi-daemon[1542]: Leaving mDNS multicast group on interface wlp3s0.IPv4 with address 192.168.1.206.
May 27 00:34:20 aerie avahi-daemon[1542]: Interface wlp3s0.IPv4 no longer relevant for mDNS.
May 27 00:34:20 aerie systemd-resolved[1501]: wlp3s0: Bus client reset search domain list.
May 27 00:34:20 aerie dnsmasq[2068]: reading /etc/resolv.conf
May 27 00:34:20 aerie systemd-resolved[1501]: wlp3s0: Bus client set default route setting: no
May 27 00:34:20 aerie dnsmasq[2068]: using nameserver 127.0.0.53#53
May 27 00:34:20 aerie systemd-resolved[1501]: wlp3s0: Bus client reset DNS server list.
May 27 00:34:20 aerie audit[1833]: NETFILTER_CFG table=firewalld:14 family=1 entries=41 op=nft_unregister_rule pid=1833 subj=system_u:system_r:firewalld_t:s0 comm="firewalld"
May 27 00:34:20 aerie NetworkManager[1860]: <info>  [1716766460.6141] device (wlp3s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
May 27 00:34:20 aerie NetworkManager[1860]: <info>  [1716766460.6266] device (wlp3s0): set-hw-addr: reset MAC address to 98:22:EF:D7:17:8D (unmanage)
May 27 00:34:20 aerie chronyd[1830]: Source 80.82.244.120 offline
May 27 00:34:20 aerie chronyd[1830]: Source 80.87.128.222 offline
May 27 00:34:20 aerie chronyd[1830]: Source 162.159.200.123 offline
May 27 00:34:20 aerie chronyd[1830]: Can't synchronise: no selectable sources
May 27 00:34:20 aerie chronyd[1830]: Source 85.199.214.98 offline
May 27 00:34:20 aerie systemd[1]: Reached target sleep.target - Sleep.
May 27 00:34:20 aerie wpa_supplicant[1918]: p2p-dev-wlp3s0: CTRL-EVENT-DSCP-POLICY clear_all
May 27 00:34:20 aerie wpa_supplicant[1918]: p2p-dev-wlp3s0: CTRL-EVENT-DSCP-POLICY clear_all
May 27 00:34:20 aerie wpa_supplicant[1918]: nl80211: deinit ifname=p2p-dev-wlp3s0 disabled_11b_rates=0
May 27 00:34:20 aerie systemd[1]: Starting nvidia-suspend.service - NVIDIA system suspend actions...
May 27 00:34:20 aerie suspend[65334]: nvidia-suspend.service
May 27 00:34:20 aerie logger[65334]: <13>May 27 00:34:20 suspend: nvidia-suspend.service
May 27 00:34:20 aerie wpa_supplicant[1918]: wlp3s0: CTRL-EVENT-DSCP-POLICY clear_all
May 27 00:34:20 aerie wpa_supplicant[1918]: wlp3s0: CTRL-EVENT-DSCP-POLICY clear_all
May 27 00:34:20 aerie wpa_supplicant[1918]: nl80211: deinit ifname=wlp3s0 disabled_11b_rates=0
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (**) Option "fd" "41"
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) event2  - Power Button: device removed
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (**) Option "fd" "44"
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) event8  - Video Bus: device removed
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (**) Option "fd" "45"
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) event7  - Video Bus: device removed
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (**) Option "fd" "46"
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) event1  - Power Button: device removed
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (**) Option "fd" "47"
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (**) Option "fd" "48"
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (**) Option "fd" "52"
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) event12 - Ideapad extra buttons: device removed
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (**) Option "fd" "53"
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) event3  - AT Translated Set 2 keyboard: device removed
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (**) Option "fd" "54"
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) event11 - SynPS/2 Synaptics TouchPad: device removed
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (**) Option "fd" "47"
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) event5  - Logitech Wireless Keyboard PID:4023: device removed
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (**) Option "fd" "48"
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) event6  - Logitech Wireless Mouse: device removed
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) AIGLX: Suspending AIGLX clients for VT switch
May 27 00:34:21 aerie kernel: rfkill: input handler enabled
May 27 00:34:21 aerie gsd-media-keys[3550]: Unable to get default source
May 27 00:34:21 aerie gsd-media-keys[3550]: Unable to get default sink
May 27 00:34:21 aerie bluetoothd[1544]: Endpoint unregistered: sender=:1.81 path=/MediaEndpoint/A2DPSource/ldac
May 27 00:34:21 aerie bluetoothd[1544]: Endpoint unregistered: sender=:1.81 path=/MediaEndpoint/A2DPSink/aac
May 27 00:34:21 aerie bluetoothd[1544]: Endpoint unregistered: sender=:1.81 path=/MediaEndpoint/A2DPSource/aac
May 27 00:34:21 aerie bluetoothd[1544]: Endpoint unregistered: sender=:1.81 path=/MediaEndpoint/A2DPSink/sbc
May 27 00:34:21 aerie bluetoothd[1544]: Endpoint unregistered: sender=:1.81 path=/MediaEndpoint/A2DPSource/sbc
May 27 00:34:21 aerie bluetoothd[1544]: Endpoint unregistered: sender=:1.81 path=/MediaEndpoint/A2DPSink/sbc_xq
May 27 00:34:21 aerie bluetoothd[1544]: Endpoint unregistered: sender=:1.81 path=/MediaEndpoint/A2DPSource/sbc_xq
May 27 00:34:21 aerie bluetoothd[1544]: Endpoint unregistered: sender=:1.81 path=/MediaEndpoint/A2DPSource/faststream
May 27 00:34:21 aerie bluetoothd[1544]: Endpoint unregistered: sender=:1.81 path=/MediaEndpoint/A2DPSource/faststream_duplex
May 27 00:34:21 aerie bluetoothd[1544]: Endpoint unregistered: sender=:1.81 path=/MediaEndpoint/A2DPSink/opus_05
May 27 00:34:21 aerie bluetoothd[1544]: Endpoint unregistered: sender=:1.81 path=/MediaEndpoint/A2DPSource/opus_05
May 27 00:34:21 aerie bluetoothd[1544]: Endpoint unregistered: sender=:1.81 path=/MediaEndpoint/A2DPSink/opus_05_duplex
May 27 00:34:21 aerie bluetoothd[1544]: Endpoint unregistered: sender=:1.81 path=/MediaEndpoint/A2DPSource/opus_05_duplex
May 27 00:34:21 aerie uresourced[2122]: Setting resources on user-1000.slice (MemoryMin: 0, MemoryLow: 0, CPUWeight: 100, IOWeight: 100)
May 27 00:34:21 aerie uresourced[2122]: Setting resources on user@1000.service (MemoryMin: 0, MemoryLow: 0, CPUWeight: 100, IOWeight: 100)
May 27 00:34:21 aerie uresourced[2122]: Setting resources on user.slice (MemoryMin: 0, MemoryLow: 0, CPUWeight: -, IOWeight: -)
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) systemd-logind: got pause for 13:65
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) systemd-logind: got pause for 13:69
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) systemd-logind: got pause for 13:66
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) systemd-logind: got pause for 13:75
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) systemd-logind: got pause for 13:71
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) systemd-logind: got pause for 13:67
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) systemd-logind: got pause for 13:72
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) systemd-logind: got pause for 13:70
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) systemd-logind: got pause for 13:76
May 27 00:34:21 aerie /usr/libexec/gdm-x-session[2965]: (II) systemd-logind: got pause for 226:0
May 27 00:34:21 aerie systemd[1]: nvidia-suspend.service: Deactivated successfully.
May 27 00:34:21 aerie systemd[1]: Finished nvidia-suspend.service - NVIDIA system suspend actions.
May 27 00:34:21 aerie audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=nvidia-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=?>
May 27 00:34:21 aerie audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=nvidia-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? >
May 27 00:34:21 aerie systemd[1]: Starting systemd-suspend.service - System Suspend...
May 27 00:34:21 aerie systemd-sleep[65368]: Entering sleep state 'suspend'...
-- Boot a911b662b3aa4f61a4427124e8b4b8a3 --
May 27 05:23:32 aerie kernel: Linux version 6.8.10-200.fc39.x86_64 (mockbuild@f9cdabb4fa2740de85a9acfb428ce3fd) (gcc (GCC) 13.2.1 20240316 (Red Hat 13.2.1-7), GNU ld version 2.40-14.fc39) #1 SMP PREEMPT_DYNAMIC>

As you can see, there’s nothing in the logs about me trying to wake the system up. The next message is the new boot from after I forced shutdown.

I’m not sure how should I investigate this further, but I’m hoping I’m not the only with this issue.

Removed server

Could you post your system specs here using inxi -Fxzz in </> preformatted text?

There have been many issues with Wake from Suspend here in the last few months with different 6.7.+ kernels. I am currently on 6.8.11 and do not have issues.

Also, if you know your 5.15 LTS kernel is good, then keep it and use it as a fall back.

This reminds me of black screen issues that sre back for me it is sonething to do with power managment prob since i have been having this daily on my laptopbwuthbexternal screen and it wont show anything on both screens untill ibdisconnect external monitor and then i get laptop screen back and log in connect external screen bqck and all wirks again. Could this be similar onnyour case too?

I was having a similar problem a few weeks back. It eventually went away after I updated, but I never was able to pinpoint what was causing it.

System:
  Kernel: 5.15.160-200.fc39.x86_64 arch: x86_64 bits: 64 compiler: gcc
    v: 2.40-14.fc39
  Console: pty pts/2 Distro: Fedora Linux 39 (Workstation Edition)
Machine:
  Type: Laptop System: LENOVO product: 80WK v: Lenovo Y520-15IKBN
    serial: <filter>
  Mobo: LENOVO model: LNVNB161216 v: NO DPK serial: <filter> UEFI: LENOVO
    v: 4KCN40WW date: 10/17/2017
Battery:
  ID-1: BAT0 charge: 31.0 Wh (100.0%) condition: 31.0/45.0 Wh (68.9%)
    volts: 12.7 min: 11.5 model: SMP L16M3P24 status: full
  Device-1: hidpp_battery_0 model: Logitech Wireless Keyboard
    charge: 55% (should be ignored) status: discharging
CPU:
  Info: quad core model: Intel Core i5-7300HQ bits: 64 type: MCP
    arch: Kaby Lake rev: 9 cache: L1: 256 KiB L2: 1024 KiB L3: 6 MiB
  Speed (MHz): avg: 2289 high: 3289 min/max: 800/3500 cores: 1: 1128 2: 3149
    3: 3289 4: 1592 bogomips: 19999
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: Intel HD Graphics 630 vendor: Lenovo driver: i915 v: kernel
    arch: Gen-9.5 bus-ID: 00:02.0
  Device-2: NVIDIA GP107M [GeForce GTX 1050 Ti Mobile] vendor: Lenovo
    driver: nvidia v: 550.90.07 arch: Pascal bus-ID: 01:00.0
  Device-3: Syntek EasyCamera driver: uvcvideo type: USB bus-ID: 1-6:3
  Display: server: X.Org v: 1.20.14 with: Xwayland v: 23.2.7 driver: X:
    loaded: modesetting,nvidia unloaded: fbdev,vesa dri: iris gpu: i915
    resolution: 1: 1920x1200~60Hz 2: 1920x1080~60Hz
  API: OpenGL v: 4.6 vendor: intel mesa v: 23.3.6 glx-v: 1.4
    direct-render: yes renderer: Mesa Intel HD Graphics 630 (KBL GT2)
  API: EGL Message: EGL data requires eglinfo. Check --recommends.
Audio:
  Device-1: Intel CM238 HD Audio vendor: Lenovo driver: snd_hda_intel
    v: kernel bus-ID: 00:1f.3
  API: ALSA v: k5.15.160-200.fc39.x86_64 status: kernel-api
  Server-1: PipeWire v: 1.0.7 status: n/a (root, process)
Network:
  Device-1: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter
    vendor: Lenovo driver: ath10k_pci v: kernel bus-ID: 03:00.0 temp: 47.0 C
  IF: wlp3s0 state: up mac: <filter>
  Device-2: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
    vendor: Lenovo driver: r8169 v: kernel port: 3000 bus-ID: 04:00.0
  IF: enp4s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
  IF-ID-1: virbr0 state: up speed: 10 Mbps duplex: unknown mac: <filter>
  IF-ID-2: virbr1 state: up speed: 10 Mbps duplex: unknown mac: <filter>
  IF-ID-3: vnet0 state: unknown speed: 10 Mbps duplex: full mac: <filter>
  IF-ID-4: vnet1 state: unknown speed: 10 Mbps duplex: full mac: <filter>
Bluetooth:
  Device-1: Qualcomm Atheros QCA61x4 Bluetooth 4.0 driver: btusb v: 0.8
    type: USB bus-ID: 1-11:4
  Report: btmgmt ID: hci0 rfk-id: 5 state: up address: <filter> bt-v: 4.2
    lmp-v: 8
Drives:
  Local Storage: total: 1.94 TiB lvm-free: 180 GiB used: 1.44 TiB (74.6%)
  ID-1: /dev/nvme0n1 vendor: Samsung model: MZVLW128HEGR-000L2
    size: 119.24 GiB temp: 35.9 C
  ID-2: /dev/sda vendor: Seagate model: ST2000LM007-1R8174 size: 1.82 TiB
    temp: 39 C
Partition:
  ID-1: / size: 118.13 GiB used: 99.19 GiB (84.0%) fs: btrfs dev: /dev/dm-0
    mapped: luks-b9a4d92b-a9b0-4931-97d5-a9d03127396c
  ID-2: /boot size: 973.4 MiB used: 577.3 MiB (59.3%) fs: ext4
    dev: /dev/nvme0n1p2
  ID-3: /boot/efi size: 99.8 MiB used: 19 MiB (19.0%) fs: vfat
    dev: /dev/nvme0n1p1
  ID-4: /home size: 118.13 GiB used: 99.19 GiB (84.0%) fs: btrfs
    dev: /dev/dm-0 mapped: luks-b9a4d92b-a9b0-4931-97d5-a9d03127396c
Swap:
  ID-1: swap-1 type: zram size: 8 GiB used: 1.57 GiB (19.6%) dev: /dev/zram0
  ID-2: swap-2 type: partition size: 20 GiB used: 0 KiB (0.0%)
    dev: /dev/dm-4 mapped: hdd-swap
Sensors:
  System Temperatures: cpu: 42.0 C pch: 43.0 C mobo: N/A
  Fan Speeds (rpm): N/A
Info:
  Memory: total: 16 GiB available: 15.5 GiB used: 7.68 GiB (49.6%)
    igpu: 32 MiB
  Processes: 445 Uptime: 21h 22m Init: systemd target: graphical (5)
  Packages: 89 Compilers: gcc: 13.3.1 Shell: Sudo v: 1.9.15p5 inxi: 3.3.34

My issues were with 6.8.10 if I remember correctly.

If it was only few weeks back, give it time. I thought it was sorted a couple times, until it happened again. It seems to be random and there can be breaks when it doesn’t happen for a while (and also times where it happens fairly often).

Good practice would be to keep a couple kernels in when you know you have a good one. Depending on your bootlloader you can change that and since you are suing a LTS you probably should.

Wake/Suspend will be different for everyone, Power/Wifi/Bluetooth are all affected at times as well.

So it looks like the problem isn’t with waking up, it’s with putting it to sleep.
For some reason, the process doesn’t finish and the device gets stuck in powered up mode.

I wasn’t able to spot any difference in the systemd journal logs between a successful sleep and unsuccessful one. Both end with that “entering sleep state ‘suspend’” message as is shown in the original post.

It looks like the latest 5.15 LTS kernels have the same problem as the current fedora kernel, so there’s no longer any benefit in using the LTS version.

I wonder if there are any other logs, outside the systemd journal or anything else I should check.

Given that changing the kernel version seemed to have helped before, I think it’s more likely to be software issue than a hardware issue.

PS: couple times I got a seemingly similar problem when powering down… it would go through all the steps but wouldn’t actually power down, due to the fact that I don’t usually shutdown (mostly just reboot, which seems to work fine), I’m not yet sure if this is in fact related or if it happens with about the same frequency, nor if it does actually get stuck there permanently or if it simply takes too long.

Hi all.
I know I am not the first or only one that is complaining about the Fedora suspend mode. But, I wanted to get help to solve this issue on my device. I am new to Linux. It’s been two months since I jumped the Windows ship. Love Linux.
I have a decent Dell desktop (XPS 8910). I do experience the issue with my PC not waking up from sleep once in a while but I have also experienced what Phalkon has indicated above. I mean at least a couple times, when my device was going to sleep or suspend mode, I could hear the fan running while the monitor had done dark, but the computer was still on (not in suspend or sleep). So, not sure this issue relates to the PC power management or GPU driver.
I have installed the NVIDIA drivers from RPM fusion like many others and update my device on a regular basis.
This suspend mode issue has become a headache. What I am wondering is why no one has found a solution for this ongoing and old issue? There must be a reason that the computer doesn’t wake up from the suspend mode every time. Personally, I experience this issue at least every one to two days. Its annoying. Any new information out there that could be helpful in addressing this issue ?

I think that suspend/wake is one of the most complicated actions that takes place on a computer. Most PCs, components, and devices are purpose-built for M$ Windows with little consideration for how they will work with other OSes. I think that it’s a miracle that it works on Linux as well as it does.

Anyway, back in early August, I bought a new Lenovo Yoga 7 with an AMD cpu/integrated gpu. It’s a fairly simple machine, but before I even installed f42 Plasma, I changed a few BIOS settings from their factory defaults. Sure enough, my system wouldn’t do the suspend/wake thing. I was perplexed, and went through a fair amount of effort trying to figure out why.

Then, at long last, I went into the BIOS menu and reset everything to their defaults. Et voila! I actually did suspend/wake afterwards. Take from that what you will. :slight_smile:

Good luck!

I believe (suspect is more accurate) that the primary issue is that manufacturers of hardware want to knock out the cheapest possible device they can manage without utterly pissing off the vast majority of their paying customers. Those customers are probably running Windows.

They spend the least amount of money they can on software development, and it all goes into Windows drivers. Those drivers work around known bugs in the firmware, weird idiosyncrasies in this chipset and that controller and so on.

Linux users have to put up with flaky drivers from a manufactuere at best, none as a rule. So we have to reverse engineer them or written from scratch based on no docs. We don’t know about the crappy code in the wifi chip that doesn’t sleep reliably so you need to send it a shutdown command at least 4 times over a 24ms period or the sound driver that may or may not turn off a signal to a speaker that causes it to fizz constantly in low power states unless you toggle this pin repeatedly until the voltage on this undocumented pin goes below 700 mv.

Ergo, we get a lower level of performance at best alongside fans that continue to spin in sleep mode and so on. The list is endless and if you spend more than a few days on a linux laptop, you probably hit at least one.

1 Like

There have been many changes affecting power management. Some of these may require vendor firmware updates. Linux developers tend to have newer systems and may unintentionally break older systems. A solution to such breakage generally requires community efforts to find details that allow developers to understand with issue without access to the affected hardware.

Without relevant error messages we can only guess at reasons. Systems with a black screen may still allow a console session () or remote login via ssh where journalctl can be used. Shutting off a system with a black screen by removing power risks damage to filesystems and may prevent saving a complete journal. You can use smartmontools (comand-line) or Gnome Disks to view the S.M.A.R.T data, which includes a count of “unsafe” shutdowns.

When reporting problems, you should ensure that you have all vendor firmware updates and have tested the most recent kernel so you aren’t chasing a solved problem.

These are all good information.
As John mentioned, I can see how the majority of the PC makers focus their testing on Win based OS. And, how this could adversly impact linux machines. If I buy a new machine, I may focus on those that are made for linux, hoping they will not have this suspend issue I am experiencing. Or, I would build one from scratch, however, this could be tricky as I am not sure from the main PC components which ones will be linux friendly to use so I can avoid having issues.
Is there a list of main PC components that can be used to build a linux machine to avoid the suspend issue? (e.g. motherboard, processor, graphics card, audio, etc.).
Should I avoid using NVIDIA all together and consider other GPU brands?

I do update my PC on a daily basis. And have seen NVIDIA drivers being updated several times. But no difference in the issue I am experiencing.

George, I thank you for your response, but I am not too tech savvy when it comes to linux. But I can confirm that I do check and update vendor firmware on my machine.
I am not familiar with the “journalctl” but ran the “smartmontools” command in the terminal. However, the response was that “command was not found”. I tried the DISK app in gnome and can see a list of attributes, but I am not sure how to interpret them. I attached a screen shot of the SMART table to my comments.
As for the kernel, I do not know how to test the kernel and how to determine whether it is the latest one. I installed Fedora 42 workstation a couple months ago and have been checking and installing the updates on a daily basis. Assuming the kernel is the latest, but again, I am not an advanced linux user and could be wrong.
Thanks again for your feedbacks.

P.S. while preparing this post, I had to step away to take care of something. When I returned, I noticed my monitor is on stand by, but the PC is still on and the fan constantly running as if, it is stuck on a process just before going to auto suspend. I had to force shut down then restart the PC.
I am assuming the two issues of the PC not waking up from the suspend and not going to auto suspend could be caused by the same issue.

There are some Web sites, such as https://linux-hardware.org/ and https://www.linux-laptop.net/ for laptops, for example, where you can do a little research on hardware that’s compatible with Linux OSes. A quick web search will likely turn up others.

I have never owned a computer with NVidia GPU hardware, but from a somewhat more than casual observation of complications for people using it, I’d say you’d probably be better off selecting AMD GPUs over NVidia, even if there might be moderate performance loss from doing so. I know that’s what I’d do for my own systems.

Good luck!

Thanks John.
I know there are a lot of talks about NVIDIA and their products, but I am not a gamer and all I want is a simple but decent PC to use on a daily basis. I was also thinking about staying away from their GPUs, lol
Do you by any chance know whether this linux suspend issue is limited to those machines using NVIDIA or other GPU could also cause this problem?

I know for a fact that it is not limited to them. :frowning:

As I mentioned earlier, suspend/wake is incredibly complicated. Problems with one or both actions failing involves power management, and any device can throw a wrench in the works by refusing to be managed. There are other reasons that things can fail in addition to that aspect.

Did you search for smartmontools in Gnome Software? The screen capture doesn’t show the full report. The command-line output provides text that can be posted here and will be found with web searches, but may need some time on the web site to learn how to use it and interprete the results.

New machines often have issues, even from vendors who support linux. My experience has been that “enterprise” grade systems a few years old from major vendors have fewer issues with linux. It takes time for linux devs to fix issues with newer hardware.

Currently, with many large enterprises reducing staff and upgrading systems to support Windows 11 and AI, there are bargain prices for refurbished models from vendors like Dell, HP, and Lenovo. Use the LHDB to see what issues affect systems you are considering. At work we wanted to provide visitors and students on work terms with access to systems identical to the ones we used, but discovered that our “enterprise” models are only available for orders of more than 1000 units (and per-unit prices lower than similar spec models from large retailers).

I guess it makes sense that buying a new machine is not really going to solve my problem. With the same logic, I guess building a new machine from scratch is not the answer either.
Ideally, I wish I could find the secret sauce for building a new machine (i.e. linux friendly motherboard, GPU, Processor, NIC, …)
I just can’t imagine that almost everyone using linux OS on their desktop has to, or is leaving with such issues.