Created attachment 1863118 [details] Log from gnome-log. Created attachment 1863118 [details] Log from gnome-log. 1. Please describe the problem: After upgraded Fedroa 35 to Kernel 5.16.10. Laptop in s2idle suspend is still drain battery quickly. And It's normal with kernel 5.16.8. 2. What is the Version-Release number of the kernel: 5.16.10 and 5.16.11 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : Kernel 5.16.10 first appeared, and 5.16.11 still have this issue. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: 1,Close the lid,Laptop get into suspend 2,You can see my thinkpad red dot led is breathing. Which is mean suspend is working. 3,Leave laptop for a long time.(Over night) 4,Open the lid. You can find that battery is o, and you have to charge it to turn on. I checked the log and can't find anything useful. The only thing I noticed is the last log is stop at "kernel: PM: suspend entry (s2idle)" . after that, My Laptop battery drain to 0. I check suspend log file with 5.16.8 kernel. I can see there is something like "Filesystems sync: 0.007 seconds" after that. So maybe the kernel 5.16.10 have some issue on suspend filesystems syncing? My laptop Thinkpad X1 Carbon 2021
Created attachment 1863119 [details] Full log
I think I have the same problem on a ThinkPad T14s Gen1. Since the last 2 kernels or so, the fan is pretty much always on, even with the lid closed the fan keeps running. I noticed it in particular when I place the ThinkPad into its bag as it will be very hot when I later take it back out. A clear indication that despite the log entries it did not really go into suspend. Here are the log entries from when I closed the lid yesterday evening: Mar 03 22:51:17 t14s systemd-logind[3138]: Lid closed. Mar 03 22:51:17 t14s systemd-logind[3138]: Suspending... Mar 03 22:51:17 t14s ModemManager[3213]: <info> [sleep-monitor] system is about to suspend Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.3896] manager: sleep: sleep requested (sleeping: no enabled: yes) Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.3899] device (p2p-dev-wlp0s20f3): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed') Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.3903] manager: NetworkManager state is now ASLEEP Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.3907] device (wlp0s20f3): state change: activated -> deactivating (reason 'sleeping', sys-iface-state: 'managed') Mar 03 22:51:17 t14s systemd[1]: Starting Network Manager Script Dispatcher Service... Mar 03 22:51:17 t14s systemd[1]: Started Network Manager Script Dispatcher Service. Mar 03 22:51:17 t14s 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" hostname=? addr=? terminal=? res=success' Mar 03 22:51:17 t14s kernel: wlp0s20f3: deauthenticating from b8:be:f4:74:78:b4 by local choice (Reason: 3=DEAUTH_LEAVING) Mar 03 22:51:17 t14s systemd-resolved[3095]: wlp0s20f3: Bus client set default route setting: no Mar 03 22:51:17 t14s systemd-resolved[3095]: wlp0s20f3: Bus client reset DNS server list. Mar 03 22:51:17 t14s wpa_supplicant[3300]: wlp0s20f3: CTRL-EVENT-DISCONNECTED bssid=b8:be:f4:74:78:b4 reason=3 locally_generated=1 Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.4203] device (wlp0s20f3): supplicant interface state: completed -> disconnected Mar 03 22:51:17 t14s wpa_supplicant[3300]: wlp0s20f3: CTRL-EVENT-DSCP-POLICY clear_all Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.4204] device (wlp0s20f3): state change: deactivating -> disconnected (reason 'sleeping', sys-iface-state: 'managed') Mar 03 22:51:17 t14s avahi-daemon[3120]: Withdrawing address record for fe80::935:e601:2536:8aaf on wlp0s20f3. Mar 03 22:51:17 t14s avahi-daemon[3120]: Leaving mDNS multicast group on interface wlp0s20f3.IPv6 with address fe80::935:e601:2536:8aaf. Mar 03 22:51:17 t14s avahi-daemon[3120]: Interface wlp0s20f3.IPv6 no longer relevant for mDNS. Mar 03 22:51:17 t14s wpa_supplicant[3300]: wlp0s20f3: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-9999 noise=9999 txrate=0 Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.4350] dhcp4 (wlp0s20f3): canceled DHCP transaction Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.4350] dhcp4 (wlp0s20f3): state changed bound -> terminated Mar 03 22:51:17 t14s avahi-daemon[3120]: Interface wlp0s20f3.IPv4 no longer relevant for mDNS. Mar 03 22:51:17 t14s avahi-daemon[3120]: Leaving mDNS multicast group on interface wlp0s20f3.IPv4 with address 192.168.1.73. Mar 03 22:51:17 t14s avahi-daemon[3120]: Withdrawing address record for 192.168.1.73 on wlp0s20f3. Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.4413] device (wlp0s20f3): set-hw-addr: set MAC address to 66:57:CA:E4:E6:F9 (scanning) Mar 03 22:51:17 t14s avahi-daemon[3120]: Joining mDNS multicast group on interface wlp0s20f3.IPv4 with address 192.168.1.73. Mar 03 22:51:17 t14s avahi-daemon[3120]: New relevant interface wlp0s20f3.IPv4 for mDNS. Mar 03 22:51:17 t14s avahi-daemon[3120]: Registering new address record for 192.168.1.73 on wlp0s20f3.IPv4. Mar 03 22:51:17 t14s avahi-daemon[3120]: Withdrawing address record for 192.168.1.73 on wlp0s20f3. Mar 03 22:51:17 t14s avahi-daemon[3120]: Leaving mDNS multicast group on interface wlp0s20f3.IPv4 with address 192.168.1.73. Mar 03 22:51:17 t14s avahi-daemon[3120]: Interface wlp0s20f3.IPv4 no longer relevant for mDNS. Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.4451] device (wlp0s20f3): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed') Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.4485] device (wlp0s20f3): set-hw-addr: reset MAC address to E8:84:A5:B1:0A:2B (unmanage) Mar 03 22:51:17 t14s wpa_supplicant[3300]: p2p-dev-wlp0s20: CTRL-EVENT-DSCP-POLICY clear_all Mar 03 22:28:37 t14s onedrive[4168]: Sync with OneDrive is complete Mar 03 22:35:07 t14s kernel: perf: interrupt took too long (2505 > 2500), lowering kernel.perf_event_max_sample_rate to 79000 Mar 03 22:51:04 t14s wireplumber[4466]: [string "policy-bluetooth.lua"]:121: bad argument #1 to 'find' (string expected, got nil) stack traceback: [C]: in function 'string.find' [string "policy-bluetooth.lua"]:121: in upvalue 'isBluez5AudioSink' [string "policy-bluetooth.lua"]:389: in function <[string "policy-bluetooth.lua"]:387> Mar 03 22:51:17 t14s systemd-logind[3138]: Lid closed. Mar 03 22:51:17 t14s systemd-logind[3138]: Suspending... Mar 03 22:51:17 t14s ModemManager[3213]: <info> [sleep-monitor] system is about to suspend Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.3896] manager: sleep: sleep requested (sleeping: no enabled: yes) Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.3899] device (p2p-dev-wlp0s20f3): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed') Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.3903] manager: NetworkManager state is now ASLEEP Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.3907] device (wlp0s20f3): state change: activated -> deactivating (reason 'sleeping', sys-iface-state: 'managed') Mar 03 22:51:17 t14s systemd[1]: Starting Network Manager Script Dispatcher Service... Mar 03 22:51:17 t14s systemd[1]: Started Network Manager Script Dispatcher Service. Mar 03 22:51:17 t14s 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" hostname=? addr=? terminal=? res=success' Mar 03 22:51:17 t14s kernel: wlp0s20f3: deauthenticating from b8:be:f4:74:78:b4 by local choice (Reason: 3=DEAUTH_LEAVING) Mar 03 22:51:17 t14s systemd-resolved[3095]: wlp0s20f3: Bus client set default route setting: no Mar 03 22:51:17 t14s systemd-resolved[3095]: wlp0s20f3: Bus client reset DNS server list. Mar 03 22:51:17 t14s wpa_supplicant[3300]: wlp0s20f3: CTRL-EVENT-DISCONNECTED bssid=b8:be:f4:74:78:b4 reason=3 locally_generated=1 Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.4203] device (wlp0s20f3): supplicant interface state: completed -> disconnected Mar 03 22:51:17 t14s wpa_supplicant[3300]: wlp0s20f3: CTRL-EVENT-DSCP-POLICY clear_all Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.4204] device (wlp0s20f3): state change: deactivating -> disconnected (reason 'sleeping', sys-iface-state: 'managed') Mar 03 22:51:17 t14s avahi-daemon[3120]: Withdrawing address record for fe80::935:e601:2536:8aaf on wlp0s20f3. Mar 03 22:51:17 t14s avahi-daemon[3120]: Leaving mDNS multicast group on interface wlp0s20f3.IPv6 with address fe80::935:e601:2536:8aaf. Mar 03 22:51:17 t14s avahi-daemon[3120]: Interface wlp0s20f3.IPv6 no longer relevant for mDNS. Mar 03 22:51:17 t14s wpa_supplicant[3300]: wlp0s20f3: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-9999 noise=9999 txrate=0 Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.4350] dhcp4 (wlp0s20f3): canceled DHCP transaction Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.4350] dhcp4 (wlp0s20f3): state changed bound -> terminated Mar 03 22:51:17 t14s avahi-daemon[3120]: Interface wlp0s20f3.IPv4 no longer relevant for mDNS. Mar 03 22:51:17 t14s avahi-daemon[3120]: Leaving mDNS multicast group on interface wlp0s20f3.IPv4 with address 192.168.1.73. Mar 03 22:51:17 t14s avahi-daemon[3120]: Withdrawing address record for 192.168.1.73 on wlp0s20f3. Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.4413] device (wlp0s20f3): set-hw-addr: set MAC address to 66:57:CA:E4:E6:F9 (scanning) Mar 03 22:51:17 t14s avahi-daemon[3120]: Joining mDNS multicast group on interface wlp0s20f3.IPv4 with address 192.168.1.73. Mar 03 22:51:17 t14s avahi-daemon[3120]: New relevant interface wlp0s20f3.IPv4 for mDNS. Mar 03 22:51:17 t14s avahi-daemon[3120]: Registering new address record for 192.168.1.73 on wlp0s20f3.IPv4. Mar 03 22:51:17 t14s avahi-daemon[3120]: Withdrawing address record for 192.168.1.73 on wlp0s20f3. Mar 03 22:51:17 t14s avahi-daemon[3120]: Leaving mDNS multicast group on interface wlp0s20f3.IPv4 with address 192.168.1.73. Mar 03 22:51:17 t14s avahi-daemon[3120]: Interface wlp0s20f3.IPv4 no longer relevant for mDNS. Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.4451] device (wlp0s20f3): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed') Mar 03 22:51:17 t14s NetworkManager[3239]: <info> [1646344277.4485] device (wlp0s20f3): set-hw-addr: reset MAC address to E8:84:A5:B1:0A:2B (unmanage) Mar 03 22:51:17 t14s wpa_supplicant[3300]: p2p-dev-wlp0s20: CTRL-EVENT-DSCP-POLICY clear_all Mar 03 22:51:17 t14s wpa_supplicant[3300]: p2p-dev-wlp0s20: CTRL-EVENT-DSCP-POLICY clear_all Mar 03 22:51:17 t14s wpa_supplicant[3300]: nl80211: deinit ifname=p2p-dev-wlp0s20 disabled_11b_rates=0 Mar 03 22:51:17 t14s chronyd[3171]: Can't synchronise: no selectable sources Mar 03 22:51:17 t14s wpa_supplicant[3300]: wlp0s20f3: CTRL-EVENT-DSCP-POLICY clear_all Mar 03 22:51:17 t14s audit[3216]: NETFILTER_CFG table=firewalld:9 family=1 entries=5 op=nft_unregister_rule pid=3216 subj=system_u:system_r:firewalld_t:s0 comm="firewalld" Mar 03 22:51:17 t14s wpa_supplicant[3300]: wlp0s20f3: CTRL-EVENT-DSCP-POLICY clear_all Mar 03 22:51:17 t14s wpa_supplicant[3300]: nl80211: deinit ifname=wlp0s20f3 disabled_11b_rates=0 Mar 03 22:51:17 t14s gnome-shell[4314]: An active wireless connection, in infrastructure mode, involves no access point? Mar 03 22:51:18 t14s systemd[1]: Reached target Sleep. Mar 03 22:51:18 t14s systemd[1]: Starting System Suspend... Mar 03 22:51:18 t14s systemd-sleep[19152]: Entering sleep state 'suspend'... Mar 03 22:51:18 t14s kernel: PM: suspend entry (s2idle) Mar 03 22:51:18 t14s kernel: Filesystems sync: 0.026 seconds fwupdmgr reports the latest updates are installed. The BIOS is at N2YET32W (1.21 )
While we figure out a fix (and please test new kernel updates as they come out to see if it fixes the issue), please either revert to the last known working kernel, or use a shutdown instead of suspend when putting it into you bag. That heat build up is the fastest way to permanently destroy a battery.
Just by chance: Could this be commit 4287509b4d21e34dc49266c6239920811e189e40 Author: Rafael J. Wysocki <rafael.j.wysocki> Date: Fri Feb 4 18:31:02 2022 +0100 ACPI: PM: s2idle: Cancel wakeup before dispatching EC GPE Can you try a 5.15.x kernel (<= 5.15.23) so check if your problems are gone?
This weekend, I tried on F35 to go back a few kernel releases, but not that far. In any case, due to another issue (nothing to do with Fedora itself), I had to reinstall my machine and installed a F36 nightly. And since doing that I don't have the issue any longer. I did try a few other things before I upgraded to F36. For instance, I tried to reset BIOS settings and I upgraded to a newer BIOS and EC release which were available from the Lenovo website, but not yet via fwupdmgr. But none of that made a difference to the issue. I did try to boot the F35 Live image, and with the live image booted, the system behaved normal. p.s. I noticed when I was looking at the BIOS, that there was a Config -> Power -> Sleep State option that could be toggled between Windows 10 (default) and Linux. I did change that setting to Linux, but this was at the time when I did the F36 install, so I don't know if this is related.
(In reply to Robert from comment #5) > p.s. I noticed when I was looking at the BIOS, that there was a Config -> > Power -> Sleep State option that could be toggled between Windows 10 > (default) and Linux. I did change that setting to Linux, but this was at the > time when I did the F36 install, so I don't know if this is related. This setting changes suspend over from s2idle to good old S3 (firmware assisted) suspend mode, so yes chances are that changing this has helped. It would be good if you can change the setting back to "Windows 10" and then test again, because Linux really should work fine in s2idle mode too.
Hi, I tried kernel 5.16.9 and it's okay. As I said on the top of this topic, this issue first appeared on Kernel 5.16.10. I think Felix is right. Archlinux users can confirm it's this commit related. ACPI: PM: s2idle: Cancel wakeup before dispatching EC GPE See: https://bbs.archlinux.org/viewtopic.php?id=274292&p=2 Yeah. Using S3 sleep mode can solve this issue. But don't forget ThinkPad X1Carbon still have S3 Sleep issue under Linux. https://bugzilla.redhat.com/show_bug.cgi?id=1965793 This bug make me have to stick with S2 Sleep.
Some Archlinux said this issue is gone on Kernel 5.17 RC7. I Checked commits and found something useful. https://patchwork.kernel.org/project/linux-pm/patch/4695836.GXAFRqVoOG@kreacher/ Maybe it's already fixed upstream. I'll try and see.
(In reply to plumlis from comment #8) > Some Archlinux said this issue is gone on Kernel 5.17 RC7. > > I Checked commits and found something useful. > > https://patchwork.kernel.org/project/linux-pm/patch/4695836. > GXAFRqVoOG@kreacher/ That commit is already present in the 5.16.y kernels since 5.16.10, these 2 changes both landed in 5.16.10: "PM: s2idle: ACPI: Fix wakeup interrupts handling" "ACPI: PM: s2idle: Cancel wakeup before dispatching EC GPE" Both these are backports from 5.17, it could be that they somehow depend on some other changes in 5.17 given the success reports with 5.17. If you want you can grab 5.17-rc7 directly from koji and give it a try: https://koji.fedoraproject.org/koji/buildinfo?buildID=1930387 See here for instructions for installing a kernel directly from koji: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt Note since this is an official build, there is no need to disable secureboot in this case.
I changed the BIOS setting back to Linux for the sleep state, and when booting the 5.17.0-0.rc7.116.fc36.x86_64 kernel, the fan came on and did not switch off any longer. After a minute the system was getting nice and toasty again. I then disconnected from the dock and closed the lid. After a bit the ThinkPad LED on the lid was no longer solid on. But the fan never turned off. So 5.17rc7 is also still broken.
I meant to say "back to windows" for the sleep state. - With the setting set to Linux, suspend works and the fan does not spin all the time. - With the setting set to Windows, suspend appears to work, but the fan keeps running all the time.
Note this is a generic comment added to several bugs at once: There have been quite a few different bug reports now about suspend/resume issues with kernel versions >= 5.16.10, there are some reports that this is caused by the patch titled "ACPI: PM: s2idle: Cancel wakeup before dispatching EC GPE". So to help debugging this further I've done 2 Fedora test kernel builds with that patch reverted: 5.16.13: https://koji.fedoraproject.org/koji/taskinfo?taskID=83901424 5.17-rc7: https://koji.fedoraproject.org/koji/taskinfo?taskID=83901915 Note these are still building atm, this should be finished in a couple of hours. See here for some generic instructions for installing a kernel directly from koji (the Fedora build-system): https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt If you are seeing suspend/resume issues with the recent Fedora kernels, please give both these builds a try and report back how they work for you.
$ uname -r 5.17.0-0.rc7.116.s2idle.fc36.x86_64 After installing the test kernel and setting the bios setting back to Windows 10, the fan was again on 100% of the time, but it seemed it did not get as hot as before. When I closed the lid, the fan kept spinning despite the fact that the ThinkPad was relatively cool. But then when I opened the lid, to wake it back up again, the ThinkPad cooled down and the fan stopped.
I did some clean to my system. I remove all boot parameter in grub. Uninstall TLP and akmod-acpi-XXX module. Disabled some scripts like " Disable fingerprint when lid is closed" Upgraded to kernel 5.16.13 official one. So far so good. no more S2idle suspend issues. I also install the kernel with out that s2idle patch provided above. Works well. I'm not sure what is the root case. because I installed TLP and akmod-acpi-XXX module,add boot parameters,enabled my srcipts back. Still no problem. Even with offical kernel 5.16.12 / 13. It's Strange, and I will keep looking at this.
Personally, I'm suspecting the EC is sometimes getting into a weird state with s2idle.
There have been other suspend/resume issues in 5.16.10+ with laptops from other vendors, so there definitely is a kernel issue with s2idle suspend/resume in 5.16.10+. I'm getting the feeling that on the x1c9 there really are 2 issues which both only trigger sometimes, making testing this problematic. One of those 2 issues is likely the same 5.16.10+ issue reported on laptops from other vendors. Note that according to other reports the s2idle issues seen on other vendors laptops don't happen with standard (no revert) 5.17 kernel builds, so it might be best to do all further testing with 5.17-rc7 or newer: https://koji.fedoraproject.org/koji/buildinfo?buildID=1930387
Just in case it got lost in the messages, I actually have a T14s Gen1.
(In reply to Robert from comment #17) > Just in case it got lost in the messages, I actually have a T14s Gen1. Ah yes that is pretty significant since that is a skylake++++++ model, where as the X1C9 is ice/tiger-lake based, so those are pretty different beasts. It turns out that the revert is not necessary for 5.17 (at least for non ThinkPad users who are also seeing problems starting with 5.16.10). Can you try 5.17-rc7 without the revert please ? : https://koji.fedoraproject.org/koji/buildinfo?buildID=1930387 If that one also does not work, please also give 5.16.13 with the revert a try: https://koji.fedoraproject.org/koji/taskinfo?taskID=83901424
Well, My X1C 9th have no issues with offical Kernel 5.16.13 about 3 days long. And today. My laptop became hot in my bad. Suspend red led is still breathing but fan is loudly. It still have the suspend issue. I'll give 5.16.13 with the revert a try and see what's going on.
(In reply to plumlis from comment #19) > Well, My X1C 9th have no issues with offical Kernel 5.16.13 about 3 days > long. > > And today. My laptop became hot in my bad. Suspend red led is still > breathing but fan is loudly. > > It still have the suspend issue. > > I'll give 5.16.13 with the revert a try and see what's going on. *bad -> bag
(In reply to Hans from comment #18) It turns out that the revert is not necessary for 5.17 (at least for non ThinkPad users who are also seeing problems starting with 5.16.10). Can you try 5.17-rc7 without the revert please ? : https://koji.fedoraproject.org/koji/buildinfo?buildID=1930387 I did, as mentioned I'm running F36 nightly with 5.17.0-0.rc7.116.fc36.x86_64 on the T14s Gen1, and with the bios sleep state set to Windows 10, the system runs very hot all the time even during suspend. If that one also does not work, please also give 5.16.13 with the revert a try: https://koji.fedoraproject.org/koji/taskinfo?taskID=83901424 That is an F35 kernel, should I try that even though I'm running F36 nightly?
(In reply to Robert from comment #21) > That is an F35 kernel, should I try that even though I'm running F36 nightly? Yes please, kernel builds and the distro release or not really coupled to each other, so running that kernel should be fine.
Some user said this issue is upower related. And new version upower solve this issue https://gitlab.freedesktop.org/upower/upower/-/releases/v0.99.17
(In reply to Hans de Goede from comment #22) > (In reply to Robert from comment #21) > > That is an F35 kernel, should I try that even though I'm running F36 nightly? > > Yes please, kernel builds and the distro release or not really coupled to > each other, so running that kernel should be fine. I downgraded to the linked kernel-5.16.13-200.s2idle.fc35.x86_64 and with the bios sleep state set to Windows 10 the system instantly started to heat up again.
(In reply to plumlis from comment #23) > Some user said this issue is upower related. > And new version upower solve this issue > https://gitlab.freedesktop.org/upower/upower/-/releases/v0.99.17 That issue is about upower not seeing that the lid is closed which in some cases can cause the system to not suspend at all, which is clearly visible from dmesg from the lack of suspend messages. That is not what is going on here AFAICT.
(In reply to Robert from comment #24) > I downgraded to the linked kernel-5.16.13-200.s2idle.fc35.x86_64 and with > the bios sleep state set to Windows 10 the system instantly started to heat > up again. Ok, so this really seems to be a different bug then the one fixed by the revert then, thank you for trying.
Kernel 5.16.14 released
I met the same issue on my Lenovo ThinkBook 14s Yoga ITL and tested 5.16.14 that fixes this issue.
I'd like to chime in that on openSUSE Tumbleweed, updating to the 5.16.14 kernel has *not* fixed the issue for me (X1C 9th).
Yesterday I upgraded my laptop to fedora 36. Kernel is also upgraded to 5.17 rc7. But my laptop can't keep in suspend longer than 2 sec. It will suspend but wake up in immediately. I don't know if it this issue related. I will try kernel 5.17 rc7 with patch reverted.
5.17.0-0.rc7.116.s2idle.fc36.x86_64 Still can't get into suspend. Went back to kernel 5.16.14 and everything is ok.
(In reply to plumlis from comment #30) > Yesterday I upgraded my laptop to fedora 36. > > Kernel is also upgraded to 5.17 rc7. > > But my laptop can't keep in suspend longer than 2 sec. > > It will suspend but wake up in immediately. > > I don't know if it this issue related. I will try kernel 5.17 rc7 with patch > reverted. For f36, I met the same issue and filed it as https://bugzilla.redhat.com/show_bug.cgi?id=2063389.
I had the same problem with 5.16. I found this: https://wiki.archlinux.org/title/Lenovo_ThinkPad_X1_Carbon_(Gen_9) I followed the instructions in the last paragraph (disable authorization options in the UEFI settings, there was one under fingerprint reader and several others in another submenu). Afterwards the issues were gone. I did not try 5.17, but the mixed results for 5.16 might result from those UEFI settings. (And then something new could be happening in 5.17.)
This issue is fixed on kernel 5.16.14 to me.
This seems like it may be the same issue? https://www.phoronix.com/scan.php?page=news_item&px=Intel-S0ix-Linux-Failure-Hot
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.