Bug 203791 - s0ix: battery drain during s2idle - Thinkpad L390
Summary: s0ix: battery drain during s2idle - Thinkpad L390
Status: NEEDINFO
Alias: None
Product: Power Management
Classification: Unclassified
Component: Hibernation/Suspend (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Rafael J. Wysocki
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-03 12:49 UTC by Florian 'rephlex' Panzer
Modified: 2021-08-12 12:00 UTC (History)
16 users (show)

See Also:
Kernel Version: 5.1.6
Tree: Mainline
Regression: No


Attachments
syslog during sleep with initcall_debug (129.90 KB, text/plain)
2019-10-03 09:04 UTC, zfarkas
Details
output of: turbostat -o ts.out rtcwake -m freeze -s 60 (5.28 KB, text/plain)
2020-01-02 08:33 UTC, Florian 'rephlex' Panzer
Details
output of: dmesg -C && turbostat -o ts.out rtcwake -m freeze -s 60 && dmesg > dmesg.out (3.35 KB, application/zip)
2020-01-02 13:47 UTC, Florian 'rephlex' Panzer
Details
Output of: turbostat -o ts-idle.out sleep 60 (5.35 KB, text/plain)
2020-01-02 16:57 UTC, Florian 'rephlex' Panzer
Details
(second) output of: dmesg -C && turbostat -o ts.out rtcwake -m freeze -s 60 && dmesg > dmesg.out (2.77 KB, application/gzip)
2020-01-04 15:33 UTC, Yanko Malinov
Details
(second) output of: turbostat -o ts-idle.out sleep 60 (5.28 KB, text/plain)
2020-01-04 15:34 UTC, Yanko Malinov
Details
ts.out and dmesg.out on Dell 5401 (3.28 KB, application/zip)
2020-01-14 09:55 UTC, Jan Pohanka
Details
ts-idle.out on Dell 5401 (5.97 KB, text/plain)
2020-01-14 09:56 UTC, Jan Pohanka
Details
Turbostat output on X1 extreme Gen 2 (5.55 KB, application/zip)
2020-01-15 03:07 UTC, anton tiniakov
Details

Description Florian 'rephlex' Panzer 2019-06-03 12:49:29 UTC
Me, and a lot of other users (see note 1) are experiencing high battery drain in s2idle on various x86-64 platforms. Laptop batteries are completely drained after around 24 hours of s2idle.

The Kernel suspends too early: Between "syncing filesystems" and "Freezing user space processes".
It should suspend after user space processes are frozen and console and disk are stopped.


Note the timestamps.

[...]
Jun 01 02:18:40 avis systemd[1]: Reached target Sleep.
Jun 01 02:18:40 avis systemd[1]: Starting Suspend...
Jun 01 02:18:40 avis systemd-sleep[27915]: Suspending system...
Jun 01 02:18:40 avis kernel: PM: suspend entry (s2idle)
Jun 01 02:18:40 avis kernel: PM: Syncing filesystems ... done.
// -------- device is sleeping at this point --------
Jun 01 12:03:59 avis kernel: Freezing user space processes ... (elapsed 0.215 seconds) done.
Jun 01 12:03:59 avis kernel: OOM killer disabled.
Jun 01 12:03:59 avis kernel: Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
Jun 01 12:03:59 avis kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Jun 01 12:03:59 avis kernel: wlp3s0: deauthenticating from cc:ce:1e:89:51:4b by local choice (Reason: 3=DEAUTH_LEAVING)
Jun 01 12:03:59 avis kernel: sd 2:0:0:0: [sda] Synchronizing SCSI cache
Jun 01 12:03:59 avis kernel: sd 2:0:0:0: [sda] Stopping disk
Jun 01 12:03:59 avis kernel: sd 2:0:0:0: [sda] Starting disk
Jun 01 12:03:59 avis kernel: OOM killer enabled.
Jun 01 12:03:59 avis wpa_supplicant[990]: wlp3s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=0 noise=9999 txrate=0
Jun 01 12:03:59 avis systemd-logind[982]: Lid opened.
Jun 01 12:03:59 avis wpa_supplicant[990]: wlp3s0: CTRL-EVENT-DISCONNECTED bssid=cc:ce:1e:89:51:4b reason=3 locally_generated=1
Jun 01 12:03:59 avis kernel: Restarting tasks ... done.
Jun 01 12:03:59 avis NetworkManager[979]: <warn> [1559383439.4503] sup-iface[0x56503c5924b0,wlp3s0]: connection disconnected (reason -3)
Jun 01 12:03:59 avis systemd[1]: Started Run anacron jobs.
[...]


I *did* successfully recreate this behaviour with ubuntu/systemd as well as gentoo/openRC using a bunch of 4.19 kernels, 5.0 kernels and the current 5.1.6 kernel.


note 1)
https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe/+bug/1825636
https://askubuntu.com/questions/828486/kernel-suspends-too-quickly-upon-resume-continues-suspend-tasks
https://askubuntu.com/questions/1072066/sleep-mode-drains-battery-very-fast/1085901#1085901
Comment 1 Florian 'rephlex' Panzer 2019-06-03 19:06:52 UTC
Additional info:
Sometimes "syncing filesystems" is done before the system actually suspends, sometimes it is done after waking the system up:


[...]
Jun  3 21:01:35 avis systemd[1]: Reached target Sleep.
Jun  3 21:01:35 avis systemd[1]: Starting Suspend...
Jun  3 21:01:35 avis systemd-sleep[2281]: Suspending system...
Jun  3 21:01:35 avis kernel: [   86.149552] PM: suspend entry (s2idle)
------- laptop sleeps here -------
Jun  3 21:01:54 avis kernel: [   86.149553] PM: Syncing filesystems ... done.
Jun  3 21:01:54 avis kernel: [   86.163111] Freezing user space processes ... (elapsed 0.002 seconds) done.
Jun  3 21:01:54 avis kernel: [   86.165328] OOM killer disabled.
Jun  3 21:01:54 avis kernel: [   86.165329] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[...]

This looks like some kind of timing issue.
Comment 2 b.lee2394 2019-06-21 19:31:06 UTC
Sorry if this is not proper etiquette, I am new to filing Linux bugs, but I'd just like to report that I am experiencing the same issue. Running Arch Linux on a Samsung NP-940. For me it seems to always suspend before "Syncing filesystems":

Jun 21 15:13:01 laptop systemd[1]: Started User suspend actions.
Jun 21 15:13:01 laptop audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295>
Jun 21 15:13:01 laptop systemd[1]: Reached target Sleep.
Jun 21 15:13:01 laptop kernel: audit: type=1130 audit(1561144381.400:80): >
Jun 21 15:13:01 laptop systemd[1]: Starting Suspend...
Jun 21 15:13:01 laptop systemd-sleep[21617]: Suspending system...
Jun 21 15:13:01 laptop kernel: PM: suspend entry (deep)
Jun 21 15:13:16 laptop kernel: PM: Syncing filesystems ... done.
Jun 21 15:13:16 laptop kernel: Freezing user space processes ... (elapsed >
Jun 21 15:13:16 laptop kernel: OOM killer disabled.
Jun 21 15:13:16 laptop kernel: Freezing remaining freezable tasks ... (ela>
Jun 21 15:13:16 laptop kernel: printk: Suspending console(s) (use no_conso>
Jun 21 15:13:16 laptop kernel: wlp2s0: deauthenticating from 60:38:e0:b4:0>
Jun 21 15:13:16 laptop kernel: sd 2:0:0:0: [sda] Synchronizing SCSI cache
Jun 21 15:13:16 laptop kernel: sd 2:0:0:0: [sda] Stopping disk
Jun 21 15:13:16 laptop kernel: ACPI: EC: interrupt blocked
Jun 21 15:13:16 laptop kernel: ACPI: Preparing to enter system sleep state>
Jun 21 15:13:16 laptop kernel: ACPI: EC: event blocked
Jun 21 15:13:16 laptop kernel: ACPI: EC: EC stopped
Jun 21 15:13:16 laptop kernel: PM: Saving platform NVS memory
Jun 21 15:13:16 laptop kernel: Disabling non-boot CPUs ...
Jun 21 15:13:16 laptop kernel: smpboot: CPU 1 is now offline
Jun 21 15:13:16 laptop kernel: smpboot: CPU 2 is now offline
Jun 21 15:13:16 laptop kernel: smpboot: CPU 3 is now offline
Jun 21 15:13:16 laptop kernel: smpboot: CPU 4 is now offline
Jun 21 15:13:16 laptop kernel: smpboot: CPU 5 is now offline
Jun 21 15:13:16 laptop kernel: smpboot: CPU 6 is now offline
Jun 21 15:13:16 laptop kernel: smpboot: CPU 7 is now offline
Jun 21 15:13:16 laptop kernel: ACPI: Low-level resume complete
Jun 21 15:13:16 laptop kernel: ACPI: EC: EC started
Jun 21 15:13:16 laptop kernel: PM: Restoring platform NVS memory
Jun 21 15:13:16 laptop kernel: Enabling non-boot CPUs ...
Jun 21 15:13:16 laptop kernel: x86: Booting SMP configuration:

So it seems like filesystems are still unsynced, tasks are not frozen, and CPUs are still online while in sleep mode. From my understanding this would be a major issue if your battery dies while suspended you can suffer extreme data loss. I may be wrong though.
Comment 3 b.lee2394 2019-06-21 19:33:55 UTC
From my previous comment about data loss, if it is true I think the priority of this bug should increase.
Comment 4 Sascha R. 2019-08-05 19:43:14 UTC
Same issue observed with Lenovo X1 Extreme (i7, Nvidia GPU) and Ubuntu 19.04. Notebook gets warm during standby and battery drains fast.

Suspend tasks seem to continue after waking up from standby resulting in messages like

parent cpu1 should not be sleeping
parent cpu2 should not be sleeping
etc.
Comment 5 Zhang Rui 2019-09-03 07:55:51 UTC
(In reply to Florian 'rephlex' Panzer from comment #0) 
> [...]
> Jun 01 02:18:40 avis systemd[1]: Reached target Sleep.
> Jun 01 02:18:40 avis systemd[1]: Starting Suspend...
> Jun 01 02:18:40 avis systemd-sleep[27915]: Suspending system...
> Jun 01 02:18:40 avis kernel: PM: suspend entry (s2idle)
> Jun 01 02:18:40 avis kernel: PM: Syncing filesystems ... done.
> // -------- device is sleeping at this point --------

how do you know device is sleeping at this point?

(In reply to Florian 'rephlex' Panzer from comment #1)
> [...]
> Jun  3 21:01:35 avis systemd[1]: Reached target Sleep.
> Jun  3 21:01:35 avis systemd[1]: Starting Suspend...
> Jun  3 21:01:35 avis systemd-sleep[2281]: Suspending system...
> Jun  3 21:01:35 avis kernel: [   86.149552] PM: suspend entry (s2idle)
> ------- laptop sleeps here -------

and also this one?

please reboot with kernel parameter "initcall_debug" and it will show the sequence of device suspend.
Comment 6 Sarowar 2019-09-24 15:54:55 UTC
Facing similar issue on Ubuntu 19.10 (dev channel)
```
$ uname -a
Linux x1 5.3.0-10-generic #11-Ubuntu SMP Mon Sep 9 15:12:17 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
```
Configuration:

* System: Lenovo Thinkpad X1 Extreme Gen2
* OS: Ubuntu 19.10
* processor: Intel® Core™ i7-9750H CPU
* Graphics: GTX 1650
* Graphics Driver: nvidia-driver-435(435.21)

```
Sep 24 03:31:37 x1 systemd[1]: Reached target Sleep.
Sep 24 03:31:37 x1 systemd[1]: Starting Suspend...
Sep 24 03:31:37 x1 systemd-sleep[20424]: Suspending system...
Sep 24 03:31:37 x1 kernel: [11779.599268] PM: suspend entry (deep)
Sep 24 03:31:37 x1 kernel: [11779.610250] Filesystems sync: 0.010 seconds
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (**) Option "fd" "28"
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (II) event2  - Power Button: device removed
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (**) Option "fd" "29"
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (II) event9  - Video Bus: device removed
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (**) Option "fd" "85"
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (II) event8  - Video Bus: device removed
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (**) Option "fd" "41"
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (II) event0  - Sleep Button: device removed
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (**) Option "fd" "38"
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (II) event3  - AT Translated Set 2 keyboard: device removed
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (**) Option "fd" "43"
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (II) event7  - ThinkPad Extra Buttons: device removed
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (**) Option "fd" "42"
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (II) event4  - Integrated Camera: Integrated C: device removed
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (**) Option "fd" "45"
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (II) event5  - SynPS/2 Synaptics TouchPad: device removed
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (**) Option "fd" "68"
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (II) event6  - TPPS/2 Elan TrackPoint: device removed
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (II) AIGLX: Suspending AIGLX clients for VT switch
Sep 24 03:31:37 x1 gnome-session-binary[1749]: gnome-session-binary[1749]: DEBUG(+): emitting SessionIsActive
Sep 24 03:31:37 x1 gnome-session-binary[1749]: DEBUG(+): emitting SessionIsActive
Sep 24 03:31:37 x1 kernel: [11779.941840] rfkill: input handler enabled
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (II) systemd-logind: got pause for 13:66
Sep 24 03:31:37 x1 /usr/lib/gdm3/gdm-x-session[1506]: (II) systemd-logind: got pause for 13:73

<-- System is sleeps here, till Sep 24 23:14:05-->

Sep 24 23:14:05 x1 kernel: [11779.979086] Freezing user space processes ... (elapsed 0.002 seconds) done.
Sep 24 23:14:05 x1 kernel: [11779.981932] OOM killer disabled.
Sep 24 23:14:05 x1 kernel: [11779.981932] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Sep 24 23:14:05 x1 kernel: [11779.983493] printk: Suspending console(s) (use no_console_suspend to debug)
Sep 24 23:14:05 x1 kernel: [11780.141282] wlp82s0: deauthenticating from b0:55:08:d3:75:57 by local choice (Reason: 3=DEAUTH_LEAVING)
Sep 24 23:14:05 x1 kernel: [11780.255113] e1000e: EEE TX LPI TIMER: 00000011
Sep 24 23:14:05 x1 kernel: [11781.792652] ACPI: EC: interrupt blocked
Sep 24 23:14:05 x1 kernel: [11781.906997] ACPI: Preparing to enter system sleep state S3
Sep 24 23:14:05 x1 kernel: [11781.916266] ACPI: EC: event blocked
Sep 24 23:14:05 x1 kernel: [11781.916267] ACPI: EC: EC stopped
Sep 24 23:14:05 x1 kernel: [11781.916269] PM: Saving platform NVS memory
Sep 24 23:14:05 x1 kernel: [11781.916307] Disabling non-boot CPUs ... (Should be done before sleeping, not during resume - I guess)
Sep 24 23:14:05 x1 kernel: [11781.918297] smpboot: CPU 1 is now offline
Sep 24 23:14:05 x1 kernel: [11781.922591] smpboot: CPU 2 is now offline
Sep 24 23:14:05 x1 kernel: [11781.925648] irq_migrate_all_off_this_cpu: 15 callbacks suppressed
Sep 24 23:14:05 x1 kernel: [11781.925651] IRQ 179: no longer affine to CPU3
Sep 24 23:14:05 x1 kernel: [11781.925661] IRQ 188: no longer affine to CPU3
Sep 24 23:14:05 x1 kernel: [11781.926701] smpboot: CPU 3 is now offline
Sep 24 23:14:05 x1 kernel: [11781.930811] smpboot: CPU 4 is now offline
Sep 24 23:14:05 x1 kernel: [11781.934041] IRQ 187: no longer affine to CPU5
Sep 24 23:14:05 x1 kernel: [11781.935082] smpboot: CPU 5 is now offline
Sep 24 23:14:05 x1 kernel: [11781.939465] smpboot: CPU 6 is now offline
Sep 24 23:14:05 x1 kernel: [11781.943845] IRQ 124: no longer affine to CPU7
Sep 24 23:14:05 x1 kernel: [11781.943854] IRQ 133: no longer affine to CPU7
Sep 24 23:14:05 x1 kernel: [11781.943866] IRQ 186: no longer affine to CPU7
Sep 24 23:14:05 x1 kernel: [11781.943875] IRQ 192: no longer affine to CPU7
Sep 24 23:14:05 x1 kernel: [11781.944894] smpboot: CPU 7 is now offline
Sep 24 23:14:05 x1 kernel: [11781.947702] IRQ 125: no longer affine to CPU8
Sep 24 23:14:05 x1 kernel: [11781.947707] IRQ 127: no longer affine to CPU8
Sep 24 23:14:05 x1 kernel: [11781.948742] smpboot: CPU 8 is now offline
Sep 24 23:14:05 x1 kernel: [11781.951059] IRQ 122: no longer affine to CPU9
Sep 24 23:14:05 x1 kernel: [11781.952102] smpboot: CPU 9 is now offline
Sep 24 23:14:05 x1 kernel: [11781.954965] smpboot: CPU 10 is now offline
Sep 24 23:14:05 x1 kernel: [11781.957955] smpboot: CPU 11 is now offline
Sep 24 23:14:05 x1 kernel: [11781.962374] ACPI: Low-level resume complete
Sep 24 23:14:05 x1 kernel: [11781.962449] ACPI: EC: EC started
Sep 24 23:14:05 x1 kernel: [11781.962449] PM: Restoring platform NVS memory
Sep 24 23:14:05 x1 kernel: [11781.963450] Enabling non-boot CPUs ...
Sep 24 23:14:05 x1 kernel: [11781.963482] x86: Booting SMP configuration:
Sep 24 23:14:05 x1 kernel: [11781.963483] smpboot: Booting Node 0 Processor 1 APIC 0x2
Sep 24 23:14:05 x1 kernel: [11781.964034] CPU1 is up
Sep 24 23:14:05 x1 kernel: [11781.964056] smpboot: Booting Node 0 Processor 2 APIC 0x4
Sep 24 23:14:05 x1 kernel: [11781.964617] CPU2 is up
Sep 24 23:14:05 x1 kernel: [11781.964637] smpboot: Booting Node 0 Processor 3 APIC 0x6
Sep 24 23:14:05 x1 kernel: [11781.965206] CPU3 is up
Sep 24 23:14:05 x1 kernel: [11781.965224] smpboot: Booting Node 0 Processor 4 APIC 0x8
Sep 24 23:14:05 x1 kernel: [11781.965834] CPU4 is up
Sep 24 23:14:05 x1 kernel: [11781.965855] smpboot: Booting Node 0 Processor 5 APIC 0xa
Sep 24 23:14:05 x1 kernel: [11781.966433] CPU5 is up
Sep 24 23:14:05 x1 kernel: [11781.966453] smpboot: Booting Node 0 Processor 6 APIC 0x1
Sep 24 23:14:05 x1 kernel: [11781.967160] CPU6 is up
Sep 24 23:14:05 x1 kernel: [11781.967183] smpboot: Booting Node 0 Processor 7 APIC 0x3
Sep 24 23:14:05 x1 kernel: [11781.967768] CPU7 is up
Sep 24 23:14:05 x1 kernel: [11781.967788] smpboot: Booting Node 0 Processor 8 APIC 0x5
Sep 24 23:14:05 x1 kernel: [11781.968387] CPU8 is up
Sep 24 23:14:05 x1 kernel: [11781.968406] smpboot: Booting Node 0 Processor 9 APIC 0x7
Sep 24 23:14:05 x1 kernel: [11781.969011] CPU9 is up
Sep 24 23:14:05 x1 kernel: [11781.969030] smpboot: Booting Node 0 Processor 10 APIC 0x9
Sep 24 23:14:05 x1 kernel: [11781.969657] CPU10 is up
Sep 24 23:14:05 x1 kernel: [11781.969677] smpboot: Booting Node 0 Processor 11 APIC 0xb
Sep 24 23:14:05 x1 kernel: [11781.970302] CPU11 is up
Sep 24 23:14:05 x1 kernel: [11781.974085] ACPI: Waking up from system sleep state S3
Sep 24 23:14:05 x1 kernel: [11782.076911] ACPI: EC: interrupt unblocked
Sep 24 23:14:05 x1 kernel: [11782.132944] ACPI: EC: event unblocked
Sep 24 23:14:05 x1 kernel: [11782.262009] iwlwifi 0000:52:00.0: Applying debug destination EXTERNAL_DRAM
Sep 24 23:14:05 x1 kernel: [11782.352678] nvme nvme1: 12/0/0 default/read/poll queues
Sep 24 23:14:05 x1 kernel: [11782.434400] iwlwifi 0000:52:00.0: FW already configured (0) - re-configuring
Sep 24 23:14:05 x1 kernel: [11782.443305] iwlwifi 0000:52:00.0: BIOS contains WGDS but no WRDS
Sep 24 23:14:05 x1 kernel: [11782.460888] nvme nvme0: Shutdown timeout set to 8 seconds
Sep 24 23:14:05 x1 kernel: [11782.477751] nvme nvme0: 12/0/0 default/read/poll queues
Sep 24 23:14:05 x1 kernel: [11782.489816] usb 1-9: reset full-speed USB device number 3 using xhci_hcd
Sep 24 23:14:05 x1 kernel: [11782.765908] usb 1-8: reset high-speed USB device number 2 using xhci_hcd
Sep 24 23:14:05 x1 kernel: [11782.924259] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4690]
Sep 24 23:14:05 x1 kernel: [11782.952220] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1160..]
Sep 24 23:14:05 x1 kernel: [11783.051175] acpi LNXPOWER:0b: Turning OFF
Sep 24 23:14:05 x1 kernel: [11783.051512] acpi LNXPOWER:06: Turning OFF
Sep 24 23:14:05 x1 kernel: [11783.051796] acpi LNXPOWER:05: Turning OFF
Sep 24 23:14:05 x1 kernel: [11783.052889] OOM killer enabled.

```
Hope this will help.
Comment 7 Yanko Malinov 2019-09-30 20:20:12 UTC
Would like to add the exact same issue affects my L390 Thinkpad as well (i7-8565K), which reports that it supports ACPI S3 sleep (deep), further extending the scope of this bug. Currently running the latest stable build of Debian Buster (10.1, kernel 4.19.0-6-amd64).
Comment 8 zfarkas 2019-10-03 09:04:15 UTC
Created attachment 285317 [details]
syslog during sleep with initcall_debug
Comment 9 zfarkas 2019-10-03 09:11:32 UTC
(In reply to Zhang Rui from comment #5)
> please reboot with kernel parameter "initcall_debug" and it will show the
> sequence of device suspend.

I have the same problem with an X1 Extreme (i7-8750H), running Ubuntu 19.04 (5.0.0-29) or Arch (5.3.1-arch1-1-ARCH), both are affected.

Added attachment containing the logs with initcall_debug: https://bugzilla.kernel.org/attachment.cgi?id=285317

The laptop seemed to have entered sleep at 10:58:12 (fans off, etc.). I've resumed the device at 10:58:43.
If I leave the define in the sleep state for a longer period of time, the bottom is warm, and battery is drained very fast.
Comment 10 Alex Mason 2019-10-04 05:11:26 UTC
could be related to the issue reported here https://bugzilla.redhat.com/show_bug.cgi?id=1748936
affects my thinkpad p1 gen 2 on kernels 5.2+. 5.1.16 has no issues
Comment 11 anton tiniakov 2019-10-07 20:56:16 UTC
duplication of the comment from https://bugzilla.redhat.com/show_bug.cgi?id=1748936

I had exactly the same issue with my "X1 Extreme Gen2"(which is almost identical to P1). 

After suspend the laptop was warm. And battery was draining at a rate around 10% in one hour. In my case removing all `acpi_osi` from kernel command line helped.  I had  "'acpi_osi=! acpi_osi=\"Windows 2009\" acpi_osi=Linux".  

After removing any `acpi_osi` lines laptop is cold during the suspend and battery draining at the rate around 1% per hour.

Kernel: 5.2.15
Lenovo Bios: 1.25
Comment 12 Alex Mason 2019-10-08 04:53:13 UTC
>After removing any `acpi_osi` lines laptop is cold during the suspend and
>battery draining at the rate around 1% per hour.
never had any of these flags set, so this issue persists without downgrading the kernel
Comment 13 Andrey Melentyev 2019-11-06 21:02:41 UTC
Same symptoms: battery drain, laptop is warm during sleep on Thinkpad X1 Extreme Gen 1.

Arch Linux, kernel 5.3.8, not using acpi_osi.
Comment 14 zfarkas 2019-11-19 19:21:01 UTC
After a BIOS upgrade on ThinkPad X1 Extreme Gen 1, the problem seems to be solved, got around 2-3% discharge in 4,5 hours:
- 20MF000LUS,
- BIOS version 1.25,
- Arch Linux
- Kernel 5.3.11-arch1-1

However, the system logs are still bit strange, assuming the CPUs go offline after waking up:
nov 19 15:56:56 x1-extreme-arch systemd[1]: Reached target Sleep.
nov 19 15:56:56 x1-extreme-arch systemd[1]: Starting Suspend...
nov 19 15:56:56 x1-extreme-arch kernel: kauditd_printk_skb: 47 callbacks suppressed
nov 19 15:56:56 x1-extreme-arch systemd-sleep[2132]: Suspending system...
nov 19 15:56:56 x1-extreme-arch kernel: PM: suspend entry (deep)
nov 19 15:56:56 x1-extreme-arch kernel: Filesystems sync: 0.007 seconds
nov 19 20:14:07 x1-extreme-arch kernel: Freezing user space processes ... (elapsed 0.015 seconds) done.
nov 19 20:14:07 x1-extreme-arch kernel: OOM killer disabled.
nov 19 20:14:07 x1-extreme-arch kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
nov 19 20:14:07 x1-extreme-arch kernel: printk: Suspending console(s) (use no_console_suspend to debug)
nov 19 20:14:07 x1-extreme-arch kernel: wlp0s20f3: deauthenticating from b4:fb:e4:48:84:d2 by local choice (Reason: 3=DEAUTH_LEAVING)
nov 19 20:14:07 x1-extreme-arch kernel: e1000e: EEE TX LPI TIMER: 00000011
nov 19 20:14:07 x1-extreme-arch kernel: ACPI: EC: interrupt blocked
nov 19 20:14:07 x1-extreme-arch kernel: ACPI: Preparing to enter system sleep state S3
nov 19 20:14:07 x1-extreme-arch kernel: ACPI: EC: event blocked
nov 19 20:14:07 x1-extreme-arch kernel: ACPI: EC: EC stopped
nov 19 20:14:07 x1-extreme-arch kernel: PM: Saving platform NVS memory
nov 19 20:14:07 x1-extreme-arch kernel: Disabling non-boot CPUs ...



(In reply to zfarkas from comment #9)
> (In reply to Zhang Rui from comment #5)
> > please reboot with kernel parameter "initcall_debug" and it will show the
> > sequence of device suspend.
> 
> I have the same problem with an X1 Extreme (i7-8750H), running Ubuntu 19.04
> (5.0.0-29) or Arch (5.3.1-arch1-1-ARCH), both are affected.
> 
> Added attachment containing the logs with initcall_debug:
> https://bugzilla.kernel.org/attachment.cgi?id=285317
> 
> The laptop seemed to have entered sleep at 10:58:12 (fans off, etc.). I've
> resumed the device at 10:58:43.
> If I leave the define in the sleep state for a longer period of time, the
> bottom is warm, and battery is drained very fast.
Comment 15 Sebastian Guttenberg 2019-12-07 15:09:14 UTC
(In reply to Zhang Rui from comment #5)
> > Jun 01 02:18:40 avis kernel: PM: suspend entry (s2idle)
> > Jun 01 02:18:40 avis kernel: PM: Syncing filesystems ... done.
> > // -------- device is sleeping at this point --------
> 
> how do you know device is sleeping at this point?

As I'm having the same issue, I want to reply to this question in place of Florian (even though it might be obvious by now). The device is probably not really sleeping (that's the problem), but it should be at this time. The position  where Florian entered his comment is after the last log-message before waking up the device by pressing a key. I.e. you could wait for arbitrary long time and no further message would appear. But as soon as you press a key to wake up the device, it first continues to fall asleep and only then wakes up. 

Could some developer say, why this bug is still marked as "NEEDINFO". What information is still needed?

It seems my kernel is not listed among the supported upstream kernels, but as this seems to affect many kernel versions, I'd like to add the information that I'm affected as well (with very similar syslog as Florian, i.e. continuing the suspend process after waking up):

* System: HP Spectre x360 - 13-ap0120ng
* OS: Debian GNU/Linux 10 (buster)
* Kernel: Linux 4.19.0-6-amd64
* processor: Intel CoreTM i7-8565U
Comment 16 Zhang Rui 2019-12-31 04:09:44 UTC
Well, S3 problems are really platform dependent, so you guys may run into different problems with similar symptom.

For this particular bug, I would focus on the problem on Thinkpad L390 only.

I will close this bug report as I have not heard from Florian 'rephlex' Panzer since the bug is filed.
Please feel free to reopen it if Florian 'rephlex' Panzer or Yanko Malinov or any people else can reproduce the problem on exactly the same model of machine.

For the others, please file a new bug instead, and please give a detailed description of the problem, together with dmesg and acpidump output when filing the bug.
Comment 17 Florian 'rephlex' Panzer 2019-12-31 17:35:07 UTC
(In reply to Zhang Rui from comment #16)
> Well, S3 problems are really platform dependent, so you guys may run into
> different problems with similar symptom.
> 
It's not a S3 issue, please have a look at the title of the bug report.


> I will close this bug report as I have not heard from Florian 'rephlex'
> Panzer since the bug is filed.

to respond to comment #5:

i know the device is sleeping because
* the power led is blinking
* the device is unreachable via network
* display is powered off
* the device will wake up when power button is pressed - as opposed to triggering the usual, configured power button action, which would indicate that the device is /not/ sleeping.
Comment 18 Zhang Rui 2020-01-01 03:03:11 UTC
(In reply to Florian 'rephlex' Panzer from comment #17)
> (In reply to Zhang Rui from comment #16)
> > Well, S3 problems are really platform dependent, so you guys may run into
> > different problems with similar symptom.
> > 
> It's not a S3 issue, please have a look at the title of the bug report.
> 
> 
> > I will close this bug report as I have not heard from Florian 'rephlex'
> > Panzer since the bug is filed.
> 
> to respond to comment #5:
> 
> i know the device is sleeping because
> * the power led is blinking
> * the device is unreachable via network
> * display is powered off
> * the device will wake up when power button is pressed - as opposed to
> triggering the usual, configured power button action, which would indicate
> that the device is /not/ sleeping.
Comment 19 Zhang Rui 2020-01-01 03:14:04 UTC
(In reply to Florian 'rephlex' Panzer from comment #17)
> (In reply to Zhang Rui from comment #16)
> > Well, S3 problems are really platform dependent, so you guys may run into
> > different problems with similar symptom.
> > 
> It's not a S3 issue, please have a look at the title of the bug report.
> 
right. it is about S2idle. But my statement is still valid, it is very likely to be different problems.
> 
> > I will close this bug report as I have not heard from Florian 'rephlex'
> > Panzer since the bug is filed.
> 
> to respond to comment #5:
> 
> i know the device is sleeping because
> * the power led is blinking
> * the device is unreachable via network
> * display is powered off
> * the device will wake up when power button is pressed - as opposed to
> triggering the usual, configured power button action, which would indicate
> that the device is /not/ sleeping.

please run "turbostat -o ts.out rtcwake -m freeze -s 60", and attach the ts.out here.
Comment 20 Florian 'rephlex' Panzer 2020-01-02 08:33:26 UTC
Created attachment 286573 [details]
output of: turbostat -o ts.out rtcwake -m freeze -s 60
Comment 21 Florian 'rephlex' Panzer 2020-01-02 08:34:22 UTC
(In reply to Zhang Rui from comment #19)
> 
> please run "turbostat -o ts.out rtcwake -m freeze -s 60", and attach the
> ts.out here.

Done, see comment #20
Comment 22 Zhang Rui 2020-01-02 13:00:38 UTC
I don't see why turbostat is still running with 10 seconds interval. are your sure the ts.out is got with the command I posted?

let's get the dmesg output altogether this time, please run

dmesg -C && turbostat -o ts.out rtcwake -m freeze -s 60 && dmesg > dmesg.out
Comment 23 Florian 'rephlex' Panzer 2020-01-02 13:47:25 UTC
> I don't see why turbostat is still running with 10 seconds interval. are
> your sure the ts.out is got with the command I posted?

Yes, absolutely. The laptop *did* go to sleep and blink the power LED, too. It woke up after the timer elapsed and i attached the file.

> let's get the dmesg output altogether this time, please run
> 
> dmesg -C && turbostat -o ts.out rtcwake -m freeze -s 60 && dmesg > dmesg.out

done, see next comment for both files.

Again, the latptop *did* go to sleep and blink the power LED, then woke up after a minute, and i uploaded the files.
Comment 24 Florian 'rephlex' Panzer 2020-01-02 13:47:58 UTC
Created attachment 286579 [details]
output of: dmesg -C && turbostat -o ts.out rtcwake -m freeze -s 60 && dmesg > dmesg.out
Comment 25 Zhang Rui 2020-01-02 14:19:52 UTC
Pkg%pc3 Pkg%pc6 Pkg%pc7 Pkg%pc8 Pkg%pc9 Pk%pc10 CPU%LPI SYS%LPI
55.76   0.00    0.00    0.02    0.00    42.96   42.91   0.00

so the system are in PC3 for 55% of the time and PC10 for 42% of the time.
The battery drains because
1. the system can not reach S0ix.
2. the system get poor PC10 residency during S2idle.

can you run "turbostat -o ts-idle.out sleep 60", so that I can see the pc10 residency for runtime idle?
Comment 26 Florian 'rephlex' Panzer 2020-01-02 16:57:37 UTC
Created attachment 286581 [details]
Output of: turbostat -o ts-idle.out sleep 60
Comment 27 Yanko Malinov 2020-01-04 15:33:58 UTC
Created attachment 286623 [details]
(second) output of: dmesg -C && turbostat -o ts.out rtcwake -m freeze -s 60 && dmesg > dmesg.out
Comment 28 Yanko Malinov 2020-01-04 15:34:41 UTC
Created attachment 286625 [details]
(second) output of: turbostat -o ts-idle.out sleep 60
Comment 29 Yanko Malinov 2020-01-04 15:35:16 UTC
To give you guys another data point, I've attached what I get when running the commands posted by Zhang Rui above, on my ThinkPad L390 (kernel 4.19.0-6-amd64):

- dmesg -C && turbostat -o ts.out rtcwake -m freeze -s 60 && dmesg > dmesg.out
- turbostat -o ts-idle.out sleep 60

Something interesting I observed was that the first command made my laptop go to sleep (screen went black, trackpad got unresponsive, 60 secs later woke back up), but it didn't blink its power LED, as opposed to Florian 'rephlex' Panzer's unit.
Comment 30 Zhang Rui 2020-01-06 05:49:01 UTC

(In reply to Yanko Malinov from comment #29)
> To give you guys another data point, I've attached what I get when running
> the commands posted by Zhang Rui above, on my ThinkPad L390 (kernel
> 4.19.0-6-amd64):
> 
> - dmesg -C && turbostat -o ts.out rtcwake -m freeze -s 60 && dmesg >
> dmesg.out

the ts.out shows that your system is working pretty well during supend-to-idle, and the system is in PC10 for 97.04% of the overall sleep time.
I'm wondering if the battery actually drains or not in this case.

> Something interesting I observed was that the first command made my laptop
> go to sleep (screen went black, trackpad got unresponsive, 60 secs later
> woke back up), but it didn't blink its power LED, as opposed to Florian
> 'rephlex' Panzer's unit.

that's another thing I don't quite understand.
In theory, when the system enters s2idle state, the power LED should not blink. Power LED only blinks when the system enters S3, i.e. suspend-to-mem.
Comment 31 Jan Pohanka 2020-01-14 09:55:45 UTC
Created attachment 286797 [details]
ts.out and dmesg.out on Dell 5401
Comment 32 Jan Pohanka 2020-01-14 09:56:16 UTC
Created attachment 286799 [details]
ts-idle.out on Dell 5401
Comment 33 Jan Pohanka 2020-01-14 10:00:54 UTC
I'm also attached by this issue on Dell 5401 running Arch Linux with latest kernel (5.4.10-arch1-1). I also tested last lts kernels (4.19, 4.14, 4.9) but none of them worked for me.
The power led is switched off during 'sleep state' in my case.
Comment 34 anton tiniakov 2020-01-15 03:07:03 UTC
Created attachment 286819 [details]
Turbostat output on X1 extreme Gen 2

Additional data points to analyze. From Lenovo X1 extreme Gen 2, bios version 1.28. Linux Kernel version 5.4.11.
Comment 35 anton tiniakov 2020-01-15 03:08:06 UTC
Additional data points to analyze.

In my case battery drain is actually okay. Battery loses approx 1% every 45 minutes.

Laptop: Lenovo X1 extreme Gen 2, bios version 1.28
Linux Kernel version 5.4.11

Attached outputs of: 

- dmesg -C && turbostat -o ts.out rtcwake -m freeze -s 60 && dmesg > dmesg.out
- turbostat -o ts-idle.out sleep 60

With `rtcwake -m freeze` my power LED also doesn't blink. If I run `rtcwake -m mem` then my power LED blinking before laptop going to sleep.
Comment 36 Zhang Rui 2020-01-15 03:19:50 UTC
Jan and Anton, please file separate bug reports, together with the detailed description of the problem and the ts.out/ts-idle.out.
Comment 37 Jan Pohanka 2020-01-16 08:09:35 UTC
Zhang, can you please clarify for me what do you mean by file separating the bug reports? I will surely provide more info, but I do not know which one. My symptoms are very similar (if not same) as Florian reports.
Comment 38 Zhang Rui 2020-06-29 08:20:14 UTC
Sorry for the late response.
S2idle issues are very platform dependent, even if they share the similar symptom. So it's better to have a bug report for each laptop model.
Please file a new bug report with your laptop model name and also the output of "dmesg -C && turbostat -o ts.out rtcwake -m freeze -s 60 && dmesg > dmesg.out".

This also applies to all the other reporters in this thread, who don't have exactly the same model of laptop, aka, Thinkpad L390.
Comment 39 SlayerProof32 2021-04-21 06:24:16 UTC
I have a somewhat similar issue. My laptop will last about 2 days if charged to 100%, then left alone. I feel that it should last about 5-6 days when asleep.

So both my laptop and my desktop have the same journalctl output in terms of timing the sleep sequence.

Apr 21 02:09:13 localhost kernel: PM: suspend entry (deep)   
Apr 21 02:09:13 localhost kernel: Filesystems sync: 0.064 seconds   
-----------Computer is sleeping. Fan and hard disk is off-----------
Apr 21 02:09:18 localhost kernel: Freezing user space processes ... (elapsed 0.004 seconds) done.
Apr 21 02:09:18 localhost kernel: OOM killer disabled.
Apr 21 02:09:18 localhost kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Apr 21 02:09:18 localhost kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Apr 21 02:09:18 localhost kernel: queueing ieee80211 work while going to suspend
Apr 21 02:09:18 localhost kernel: queueing ieee80211 work while going to suspend
Apr 21 02:09:18 localhost kernel: serial 00:04: disabled
Apr 21 02:09:18 localhost kernel: sd 2:0:0:0: [sda] Synchronizing SCSI cache
Apr 21 02:09:18 localhost kernel: sd 2:0:0:0: [sda] Stopping disk
Apr 21 02:09:18 localhost kernel: sd 10:0:0:0: [sdc] Synchronizing SCSI cache
Apr 21 02:09:18 localhost kernel: sd 4:0:0:0: [sdb] Synchronizing SCSI cache
Apr 21 02:09:18 localhost kernel: sd 4:0:0:0: [sdb] Stopping disk
Apr 21 02:09:18 localhost kernel: sd 10:0:0:0: [sdc] Stopping disk
Apr 21 02:09:18 localhost kernel: ACPI: EC: interrupt blocked
Apr 21 02:09:18 localhost kernel: ACPI: Preparing to enter system sleep state S3
Apr 21 02:09:18 localhost kernel: ACPI: EC: event blocked
Apr 21 02:09:18 localhost kernel: ACPI: EC: EC stopped
Apr 21 02:09:18 localhost kernel: PM: Saving platform NVS memory
Apr 21 02:09:18 localhost kernel: Disabling non-boot CPUs ...
Apr 21 02:09:18 localhost kernel: smpboot: CPU 1 is now offline
Apr 21 02:09:18 localhost kernel: smpboot: CPU 2 is now offline
Apr 21 02:09:18 localhost kernel: smpboot: CPU 3 is now offline
Apr 21 02:09:18 localhost kernel: smpboot: CPU 4 is now offline
Apr 21 02:09:18 localhost kernel: smpboot: CPU 5 is now offline
Apr 21 02:09:18 localhost kernel: smpboot: CPU 6 is now offline
Apr 21 02:09:18 localhost kernel: smpboot: CPU 7 is now offline
Apr 21 02:09:18 localhost kernel: smpboot: CPU 8 is now offline
Apr 21 02:09:18 localhost kernel: smpboot: CPU 9 is now offline
Apr 21 02:09:18 localhost kernel: smpboot: CPU 10 is now offline
Apr 21 02:09:18 localhost kernel: smpboot: CPU 11 is now offline
Apr 21 02:09:18 localhost kernel: ACPI: Low-level resume complete
Apr 21 02:09:18 localhost kernel: ACPI: EC: EC started
Apr 21 02:09:18 localhost kernel: PM: Restoring platform NVS memory
Apr 21 02:09:18 localhost kernel: LVT offset 0 assigned for vector 0x400
Apr 21 02:09:18 localhost kernel: Enabling non-boot CPUs ...
Apr 21 02:09:18 localhost kernel: x86: Booting SMP configuration:
Apr 21 02:09:18 localhost kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2
Apr 21 02:09:18 localhost kernel: microcode: CPU1: patch_level=0x08701021
Apr 21 02:09:18 localhost kernel: ACPI: \_PR_.C002: Found 2 idle states
Apr 21 02:09:18 localhost kernel: CPU1 is up
Apr 21 02:09:18 localhost kernel: smpboot: Booting Node 0 Processor 2 APIC 0x4
Apr 21 02:09:18 localhost kernel: microcode: CPU2: patch_level=0x08701021
Apr 21 02:09:18 localhost kernel: ACPI: \_PR_.C004: FRyzencoreound 2 idle states
Apr 21 02:09:18 localhost kernel: CPU2 is up
Apr 21 02:09:18 localhost kernel: smpboot: Booting Node 0 Processor 3 APIC 0x8
Apr 21 02:09:18 localhost kernel: microcode: CPU3: patch_level=0x08701021
Apr 21 02:09:18 localhost kernel: ACPI: \_PR_.C006: Found 2 idle states
Apr 21 02:09:18 localhost kernel: CPU3 is up
Apr 21 02:09:18 localhost kernel: smpboot: Booting Node 0 Processor 4 APIC 0xa
Apr 21 02:09:18 localhost kernel: microcode: CPU4: patch_level=0x08701021
Apr 21 02:09:18 localhost kernel: ACPI: \_PR_.C008: Found 2 idle states
Apr 21 02:09:18 localhost kernel: CPU4 is up
Apr 21 02:09:18 localhost kernel: smpboot: Booting Node 0 Processor 5 APIC 0xc
Apr 21 02:09:18 localhost kernel: microcode: CPU5: patch_level=0x08701021
Apr 21 02:09:18 localhost kernel: ACPI: \_PR_.C00A: Found 2 idle states
Apr 21 02:09:18 localhost kernel: CPU5 is up
Apr 21 02:09:18 localhost kernel: smpboot: Booting Node 0 Processor 6 APIC 0x1
Apr 21 02:09:18 localhost kernel: microcode: CPU6: patch_level=0x08701021
Apr 21 02:09:18 localhost kernel: ACPI: \_PR_.C001: Found 2 idle states
Apr 21 02:09:18 localhost kernel: CPU6 is up
Apr 21 02:09:18 localhost kernel: smpboot: Booting Node 0 Processor 7 APIC 0x3
Apr 21 02:09:18 localhost kernel: microcode: CPU7: patch_level=0x08701021
Apr 21 02:09:18 localhost kernel: ACPI: \_PR_.C003: Found 2 idle states
Apr 21 02:09:18 localhost kernel: CPU7 is up
Apr 21 02:09:18 localhost kernel: smpboot: Booting Node 0 Processor 8 APIC 0x5
Apr 21 02:09:18 localhost kernel: microcode: CPU8: patch_level=0x08701021
Apr 21 02:09:18 localhost kernel: ACPI: \_PR_.C005: Found 2 idle states
Apr 21 02:09:18 localhost kernel: CPU8 is up
Apr 21 02:09:18 localhost kernel: smpboot: Booting Node 0 Processor 9 APIC 0x9
Apr 21 02:09:18 localhost kernel: microcode: CPU9: patch_level=0x08701021
Apr 21 02:09:18 localhost kernel: ACPI: \_PR_.C007: Found 2 idle states
Apr 21 02:09:18 localhost kernel: CPU9 is up
Apr 21 02:09:18 localhost kernel: smpboot: Booting Node 0 Processor 10 APIC 0xb
Apr 21 02:09:18 localhost kernel: microcode: CPU10: patch_level=0x08701021
Apr 21 02:09:18 localhost kernel: ACPI: \_PR_.C009: Found 2 idle states
Apr 21 02:09:18 localhost kernel: CPU10 is up
Apr 21 02:09:18 localhost kernel: smpboot: Booting Node 0 Processor 11 APIC 0xd
Apr 21 02:09:18 localhost kernel: microcode: CPU11: patch_level=0x08701021
Apr 21 02:09:18 localhost kernel: ACPI: \_PR_.C00B: Found 2 idle states
Apr 21 02:09:18 localhost kernel: CPU11 is up
Apr 21 02:09:18 localhost kernel: ACPI: Waking up from system sleep state S3
Apr 21 02:09:18 localhost kernel: ACPI: EC: interrupt unblocked
Apr 21 02:09:18 localhost kernel: ACPI: EC: event unblocked
Apr 21 02:09:18 localhost kernel: sd 10:0:0:0: [sdc] Starting disk
Apr 21 02:09:18 localhost kernel: sd 4:0:0:0: [sdb] Starting disk
Apr 21 02:09:18 localhost kernel: sd 2:0:0:0: [sda] Starting disk
Apr 21 02:09:18 localhost kernel: serial 00:04: activated


Once filesystems sync, no more writing is done to the drive, therefore journalctl would not log those messages to disk (which is what you are reading).

I think the problem here maybe related to a change queued in the 5.13 kernel where ACPI devices unused do not get powered off on boot which is in conflict with the ACPI spec.
Comment 40 Georg Müller 2021-07-30 08:22:29 UTC
I have a Lenovo E14G2 intel tiger lake and I am trying to debug a similar issue.

@SlayerProof32: Could you please say which patch exactly do you mean? I am running 5.13.4 (fedora 34) and still face a problem. I would like to check if the patch is included.

For my laptop, things get worse and worse after time.
Currently (huge problem - system is really hot in s2idle suspend if in backpack for some time), when I do the "turbostat -o ts.out rtcwake -m freeze -s 60" test and look at the values as in comment #25, I get the following:

Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 Pkg%pc8 Pkg%pc9 Pk%pc10 CPU%LPI SYS%LPI
3.13    94.80   0.00    0.00    0.00    0.00    0.00    0.00    0.00   
3.13    94.80   0.00    0.00    0.00    0.00    0.00    0.00    0.00   

My system is now up for about 9 days with 3 or more daily suspends. The problem does not occur at the beginning (first couple of days), but at some point it gets really bad.

I am not that familiar in how ACPI works, but could the following commit (scheduled for v5.14) have an effect? :
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5dbf509975780851251361f2db287fdce11b7cae


As a side note:
My BIOS allows to switch from s2idle ("Windows 10") to S3 ("Linux") default sleep mode, but the BIOS has a bug which causes the Laptop to hard crash exactly 30s after wakeup (even if system is up fine, there seems to be a missing watchdog reset in the BIOS). So with only s2idle left as an option, I am in real trouble or have to do full reboots regularly.

Note You need to log in before you can comment on or make changes to this bug.