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
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.
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.
From my previous comment about data loss, if it is true I think the priority of this bug should increase.
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.
(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.
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.
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).
Created attachment 285317 [details] syslog during sleep with initcall_debug
(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.
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
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
>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
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.
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.
(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
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.
(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.
(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.
(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.
Created attachment 286573 [details] output of: turbostat -o ts.out rtcwake -m freeze -s 60
(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
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
> 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.
Created attachment 286579 [details] output of: dmesg -C && turbostat -o ts.out rtcwake -m freeze -s 60 && dmesg > dmesg.out
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?
Created attachment 286581 [details] Output of: turbostat -o ts-idle.out sleep 60
Created attachment 286623 [details] (second) output of: dmesg -C && turbostat -o ts.out rtcwake -m freeze -s 60 && dmesg > dmesg.out
Created attachment 286625 [details] (second) output of: turbostat -o ts-idle.out sleep 60
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.
(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.
Created attachment 286797 [details] ts.out and dmesg.out on Dell 5401
Created attachment 286799 [details] ts-idle.out on Dell 5401
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.
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.
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.
Jan and Anton, please file separate bug reports, together with the detailed description of the problem and the ts.out/ts-idle.out.
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.
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.
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.
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.
For me was useful this tool - https://github.com/intel/S0ixSelftestTool It pointed to NVMe SSD not entering D3cold power state.
(In reply to Jan Pohanka from comment #37) > 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. I mean you should create a new bug report. and provide the machine model name, dmesg output, acpidump, and also the output from this tool https://github.com/intel/S0ixSelftestTool.
I will close this bug report for now, as there is no response from the original reporter of this bug. S0ix is a very platform dependent feature, the same symptom (s0ix failure) may be caused by varies of reasons. If we have too many updates from different sources about "similar" problems with different root causes, we will lost easily by the conflicting information. So for the reporters in this thread, please file a new bug report, together with 1. machine model name 2. full dmesg output after boot 3. detailed description about the problem and observations 4. Analyze result from https://github.com/intel/S0ixSelftestTool