Suspend broken (s2idle) on ThinkPad T14 Gen 6 AMD after BIOS 1.17 (Fedora 43)

Suspend broken on ThinkPad T14 Gen 6 AMD after BIOS 1.17 (Fedora 43)

TL;DR: After updating the BIOS from 1.15 to 1.17 via fwupdmgr, suspend (s2idle) reliably enters sleep but never resumes. System becomes completely unresponsive and requires a hard power-off. Issue reproduces 100% of the time across kernels 6.17 and 6.18.

Overview

Good morning,
I am relatively new to fedora (coming from Ubuntu) and have been using it on my ThinkPad T14 without any issues (well, besides the usual). Now, for a few days, suspend/resume has not been working as it should. I know that it’s a tricky subject for Unix, but I never had any issues with it on Ubuntu and fedora (until now). I believe the root cause was a Lenovo-BIOS update I did some days ago (from 1.15 to 1.17 via fwupdmgr). However, I am not entirely sure, and this update also specifically blocks rollbacks to the older version.

Issue

When I close (or manually suspend) my ThinkPad, everything seems fine - the outer red LED pulses (indicating sleep or suspend). However, it never wakes up from that sleep. The power button LED also pulses, and it registers no further key presses (like sometimes when fedora froze it still managed to toggle mute, and it’s LED - not this time). Now only a force reset works, pressing the power button for like five seconds. This is reproducible 100 percent of the time for me.

BIOS-Update

Logs

Well I’ve tried a lot and have a lot of logs, but I hope these are the two most important ones.

journalctl -b -1 -o short-monotonic (suspend reaches s2idle, no resume)
...
Dec 28 22:35:31 ThinkPad systemd[1]: user.slice: Freezer state changed freezing -> frozen
Dec 28 22:35:31 ThinkPad systemd[1]: user.slice: Unit now frozen.
Dec 28 22:35:31 ThinkPad systemd[1]: Sent message type=method_return sender=org.freedesktop.systemd1 destination=n/a path=n/a interface=n/a member=n/a cookie=13 reply_cookie=1 signature=n/a error-name=n/a error-message=n/a
Dec 28 22:35:31 ThinkPad systemd[1]: user-1000.slice: Freezer state changed freezing-by-parent -> frozen-by-parent
Dec 28 22:35:31 ThinkPad systemd[1]: user-1000.slice: Unit now frozen-by-parent.
Dec 28 22:35:31 ThinkPad systemd-sleep[10607]: Successfully froze unit 'user.slice'.
Dec 28 22:35:31 ThinkPad systemd[1]: Sent message type=signal sender=org.freedesktop.systemd1 destination=n/a path=/org/freedesktop/systemd1/unit/user_2d1000_2eslice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=14 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Dec 28 22:35:31 ThinkPad systemd[1]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/systemd1/unit/user_2d1000_2eslice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=3224 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Dec 28 22:35:31 ThinkPad systemd[1]: Sent message type=signal sender=org.freedesktop.systemd1 destination=n/a path=/org/freedesktop/systemd1/unit/user_2eslice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=15 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Dec 28 22:35:31 ThinkPad systemd[1]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/systemd1/unit/user_2eslice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=3225 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Dec 28 22:35:31 ThinkPad systemd-sleep[10607]: Performing sleep operation 'suspend'...
Dec 28 22:35:31 ThinkPad kernel: PM: suspend entry (s2idle)
Dec 28 22:35:31 ThinkPad kernel: Filesystems sync: 0.020 seconds
dmesg (no kernel errors before suspend)
...
[   13.588740] snd_hda_intel 0000:c4:00.1: enabling device (0000 -> 0002)
[   13.588786] snd_hda_intel 0000:c4:00.1: Handle vga_switcheroo audio client
[   13.593667] input: keyd virtual pointer as /devices/virtual/input/input22
[   13.667067] NET: Registered PF_QIPCRTR protocol family
[   13.680207] snd_hda_intel 0000:c4:00.1: bound 0000:c4:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu])
[   13.681511] input: HD-Audio Generic HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:08.1/0000:c4:00.1/sound/card0/input23
[   13.681572] input: HD-Audio Generic HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:08.1/0000:c4:00.1/sound/card0/input24
[   13.681601] input: HD-Audio Generic HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:08.1/0000:c4:00.1/sound/card0/input25
[   13.681634] input: HD-Audio Generic HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:08.1/0000:c4:00.1/sound/card0/input26
[   13.746962] snd_hda_codec_alc269 hdaudioC1D0: ALC257: picked fixup  for PCI SSID 17aa:0000
[   13.747380] snd_hda_codec_alc269 hdaudioC1D0: autoconfig for ALC257: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   13.747382] snd_hda_codec_alc269 hdaudioC1D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[   13.747384] snd_hda_codec_alc269 hdaudioC1D0:    hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
[   13.747384] snd_hda_codec_alc269 hdaudioC1D0:    mono: mono_out=0x0
[   13.747385] snd_hda_codec_alc269 hdaudioC1D0:    inputs:
[   13.747386] snd_hda_codec_alc269 hdaudioC1D0:      Mic=0x19
[   13.787667] input: HD-Audio Generic Mic as /devices/pci0000:00/0000:00:08.1/0000:c4:00.6/sound/card1/input27
[   13.787895] input: HD-Audio Generic Headphone as /devices/pci0000:00/0000:00:08.1/0000:c4:00.6/sound/card1/input28
[   13.916086] mt7925e 0000:c2:00.0: WM Firmware Version: ____000000, Build Time: 20251015213023
[   14.738414] mt7925e 0000:c2:00.0 wlp194s0: renamed from wlan0
[   14.778370] Generic FE-GE Realtek PHY r8169-0-c300:00: attached PHY driver (mii_bus:phy_addr=r8169-0-c300:00, irq=MAC)
[   14.878323] r8169 0000:c3:00.0 enp195s0f0: Link is Down
[   15.123568] Bluetooth: hci0: Device setup in 1787547 usecs
[   15.123580] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
[   15.225144] Bluetooth: hci0: AOSP extensions version v1.00
[   15.225164] Bluetooth: hci0: AOSP quality report is supported
[   15.314889] Bluetooth: MGMT ver 1.23
[   17.729369] wlp194s0: authenticate with e0:08:55:4f:9a:23 (local address=c6:db:dc:e5:37:a0)
[   18.091232] wlp194s0: send auth to e0:08:55:4f:9a:23 (try 1/3)
[   18.095925] wlp194s0: authenticated
[   18.100389] wlp194s0: associate with e0:08:55:4f:9a:23 (try 1/3)
[   18.119087] wlp194s0: RX AssocResp from e0:08:55:4f:9a:23 (capab=0x1511 status=0 aid=4)
[   18.165203] wlp194s0: associated
[   18.411555] wlp194s0: Limiting TX power to 23 (23 - 0) dBm as advertised by e0:08:55:4f:9a:23
[   25.639586] Bluetooth: RFCOMM TTY layer initialized
[   25.639601] Bluetooth: RFCOMM socket layer initialized
[   25.639604] Bluetooth: RFCOMM ver 1.11
[   26.490862] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[   26.565211] rfkill: input handler disabled
[   34.036503] systemd-journald[1085]: File /var/log/journal/3347ff3c314140699d9e6e93707b0ef9/user-1000.journal corrupted or uncleanly shut down, renaming and replacing.
[   34.481877] rfkill: input handler enabled
[   35.430518] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[   35.532283] rfkill: input handler disabled
[   36.620192] input: solaar-keyboard as /devices/virtual/input/input29
[   39.219728] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[   45.856753] evm: overlay not supported
/sys/power/mem_sleep (available suspend modes)
[s2idle]
cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.18.2-00.fc43.x86_64 root=UUID=05774ac4-cc5e-40d6-be2c-8d19b3ddb9f6 ro rootflags=subvol=root rd.luks.uuid=luks-c0508292-b2e9-4df6-b8bc-8aa3027314fb rhgb quiet amdgpu.runpm=0 amd_pstate=active pcie_port_pm=off amd_pmc.debug=1 amd_pmc.enable=0

Tried

I tried a lot of stuff, from all kinds of sources (Reddit, the forum, etc.) without luck.

  • Using different kernels (the default was 6.17, however I found similar issues that mentioned that 6.18.x fixed it for them, not for this particular issue - added the newer kernel using this guide).
  • Adding various parameters to GRUB, including amd_pmc.enable=0.
  • Disabling Wi-Fi and Bluetooth (including rfkill system-sleep hooks) as I’ve read it could be a driver issue related to this.
  • GNOME settings vs manual suspend made no difference.
  • Checking logs before and after forced reboot (see below).

System

It is a relatively new ThinkPad T14 Gen 6 (AMD) which never had any issues related to sleep and suspend.

fastfetch
OS: Fedora Linux 43 (Workstation Edition) x86_64
Host: 21QJCTO1WW (ThinkPad T14 Gen 6)
Kernel: Linux 6.18.2-00.fc43.x86_64
Uptime: 33 mins
Packages: 2176 (rpm), 36 (flatpak)
Shell: bash 5.3.0
Display (LEN414D): 2880x1800 @ 120 Hz (as 1440x900) in 14" [Built-in]
DE: GNOME 49.2
WM: Mutter (Wayland)
WM Theme: adw-gtk3-dark
Theme: adw-gtk3-dark [GTK2/3/4]
Icons: Adwaita [GTK2/3/4]
Font: Adwaita Sans (11pt) [GTK2/3/4]
Cursor: Adwaita (24px)
Terminal: Ptyxis 49.2
Terminal Font: Adwaita Mono (11pt)
CPU: AMD Ryzen AI 7 PRO 350 (16) @ 5.09 GHz
GPU: AMD Radeon 860M Graphics [Integrated]
Memory: 4.44 GiB / 27.04 GiB (16%)
Swap: 0 B / 8.00 GiB (0%)
Disk (/): 183.69 GiB / 951.27 GiB (19%) - btrfs
Local IP (wlp194s0): 192.168.178.109/24
Battery (5B11M90125): 42% [Discharging]
Locale: en_GB.UTF-8

Similar Issues

There are many issues related to sleep/suspend, unfortunately I found no solution there.

Next Steps

As I said in the beginning, I am relatively new to fedora (but not Linux). But I think this is a bug coming from the BIOS update, so I would contact Lenovo next (or send them the bug report) but as I found no similar bugs related to the BIOS anywhere, I wanted to ask before sending it. So, has anyone with a ThinkPad (…) updated to BIOS 1.17 seen similar suspend behaviour?

Thank you!

Updates

All the stuff that happened.

  • 2025-12-29T11:06:00Z - @kaffekask experiences the same issue on a HP Spectre
  • 2025-12-29T12:21:00Z - someone on the Fediverse also has the issue on a Thinkpad.
  • 2025-12-29T13:33:00Z - Lenovo Support reached out and suggested rolling back to the previous BIOS-version (and also mentioned they don’t test on Linux systems).

I also have a broken suspend since a few days on Fedora 43. No recent BIOS update, just ordinary F43 updates. Not sure what was updated when it was broken.

HP HP Spectre x360 2-in-1 Laptop 14-ef0xxx
12th Gen Intel® Core™ i5-1235U × 12
Linux 6.17.12-300.fc43.x86_64

1 Like

Interesting, thank you. I wasn’t sure about the time when the issue appeared, but couldn’t think of anything else besides the BIOS-update. Hmm, will definitely check more other things now!

So I heard back from Lenovo (Germany) and they suggested rolling back to the previous BIOS-version.

Please disable BIOS rollback and then try setting your BIOS to an older version.

We do not test our systems with Linux operating systems, only with Windows. Therefore, I cannot tell you for sure whether there will be a BIOS or firmware update available soon to fix your problem.

While the suspend-thingy bothers me, I think I don’t want to roll back (the guide I saw seemed like hell haha) so I’ll see if there will be another solution. :smile:

After a BIOS update, sometimes it may help to load the BIOS setup defaults. Load BIOS default settings, save and exit. Then after a reboot enter BIOS again to apply your custom settings if needed.

2 Likes

I will just mention this for something to try:

I have an old Thinkpad X1 Carbon and it will only wake from suspend using a short press on the power button or by pressing the Fn key.

1 Like

omg? This seems to have done it! Thank you, @anotheruser ! I’ll see if it remains fixed and update my comment later. :grin:
And thank you @cbravo - will try if I encounter it again.

1 Like

I would like to add my current experience with ThinkPad 16s Gen 4, purchased just last week. Without using the preinstalled Windows, I immediately installed Fedora 43 and naturally updated the system and BIOS. I am experiencing the same issue, I cannot wake the laptop from a “deep suspend”, I can, however, change the keyboard backlight. Also, NumLock, FnLock, and mic mute LED indicators are on.

My experience with ThinkPad E14 G3 running Debian was that the only way to wake the system was to change the keyboard backlight. This does not help here.

I tried the trick mentioned in this thread to load the BIOS defaults, that hasn’t helped either.

I used the term “deep suspend”, because shortly after putting the laptop into “suspend”, I still can wake it easily. It is only after some time that it becomes unresponsive. Could this be preventable, perhaps?

1 Like

I think I was also able to change the keyboard backlight, though that was the only thing.

Oof, seems like this issue is like many smaller issues at once.

Here I have no clue, however sometimes my laptop fell into a “shallow sleep” (haha) where it only turned off its screen and not actually suspended itself. So maybe this is happening here?

1 Like

I have been looking into man sleep.conf.d, it seems that suspend is the mode I can wake the laptop from, hibernate, however is the one causing issues in my case.

I have created /etc/systemd/sleep.conf.d/hibernate.conf with this line:

[Sleep]
AllowHibernation=no

I will report back if this resolves my problem. It’s not ideal to get rid of hibernation completely, but I guess it’s better than hard rebooting the laptop every time. Also, the behavior I described and incorrectly termed as “deep suspend” seems to be the mode suspend-then-hibernate.

1 Like

Interesting, because with my setup there is no hibernate available at all.

Hibernate will not work unless the user has a properly defined physical swap space at least equal in size to the installed system RAM. It also requires an entry in the kernel boot command line to tell the kernel where that physical swap space is located in order to resume from hibernation.

It seems anymore that hibernation is seldom used so it is no longer automatically configured. This goes right along with the change from using physical swap to using zram virtual swap on most users systems.

2 Likes

Hibernation can be enabled by

  1. create a partition of the desires swap size and mark it as fedora swap (gdisk, fdisk, or gparted work well for this). If you need to manipulate other partitions to gain space for swap gparted would be the best choice.
  2. format the new partition as swap with mkswap
  3. find the UUID of the new swap partition with lsblk -f (There are other ways but this one is seems simplest)
  4. activate swap on the new swap partition with swapon UUID=<UUID> using the UUID as seen in step 3.
  5. verify the swap partition is active with swapop to ensure it lists the new swap partition just added.
  6. add the entry to the kernel command line with grubby.
    sudo grubby --update-kernel=ALL --args="resume=<UUID>" using the UUID identified in step 3.

At this point hibernate should work properly.
This also can be done easily with a swap file (instead of partition) on the root file system if using ext4, but seems to require different steps to create a swap file on a btrfs file system.

2 Likes

I’ve been seeing weird behavior; but not this extreme. Razer laptop from 2020. After wake from sleep I log in, and within a few seconds the system goes back to sleep. The second time I wake and log in it’s fine.

Whatever is going on is affecting more than Thinkpads. But in different ways.

1 Like