Bug 201307

Summary:	Charging state does not change when Asus Zenbook suspended
Product:	Power Management	Reporter:	Jason Gambrel (jaygambrel)
Component:	Hibernation/Suspend	Assignee:	Zhang Rui (rui.zhang)
Status:	NEEDINFO ---
Severity:	normal	CC:	apmbugs, henry.eduardo, kernel, kristian, lenb, markovs.i.mail, qantas94heavy, rephlex, rui.zhang, yu.c.chen
Priority:	P1
Hardware:	Intel
OS:	Linux
Kernel Version:	4.18.11	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	dmesg, cable plugged in, very first step dmesg, cable unplugged, very last step acpidump acpi-interrupt-after-plug acpi-interrupt-after-unplug acpi-interrupt-before-plug interrupt-after-plug interrupt-after-unplug interrupt-before-plug power-supply-after-plug power-supply-after-unplug power-supply-before-plug

Description Jason Gambrel 2018-10-02 01:37:28 UTC

Asus Zenbook UX430U.  Linux Mint 19 Tara.

Will charge while suspended IF charger is plugged in BEFORE suspending and charging indicator on side of machine will indicate it is charging.  If machine is suspended first then plugged in, charging indicator will not change and the machine will not charge, battery level is the same or lower after resuming.  Tested on mainline Kernel 4.18.10 and 4.18.11.  Same behaviour with 4.15 series kernel preloaded in Linux Mint.

Comment 1 Florian 'rephlex' Panzer 2018-10-02 08:54:00 UTC

Same on an Asus Zenbook UX331UN.

However, this happens if
-------
# cat /sys/power/mem_sleep
[s2idle] deep
-------

If you boot with kernel cmdline mem_sleep_default=deep this is issue goes away and the charging state changes as soon as you plug/unplug ac power.

But: If you go to "deep" sleep, the system will ONLY fully resume from standby if you have ac plugged in. If you wake the system up while on battery, the system freezes.

Comment 2 Jason Gambrel 2018-10-03 02:08:20 UTC

(In reply to Florian 'rephlex' Panzer from comment #1)
> Same on an Asus Zenbook UX331UN.
> 
> However, this happens if
> -------
> # cat /sys/power/mem_sleep
> [s2idle] deep
> -------
> 
> If you boot with kernel cmdline mem_sleep_default=deep this is issue goes
> away and the charging state changes as soon as you plug/unplug ac power.
> 
> But: If you go to "deep" sleep, the system will ONLY fully resume from
> standby if you have ac plugged in. If you wake the system up while on
> battery, the system freezes.

Thanks for the tip on the kernel cmdline mem_sleep_default=deep.  I tested it on my machine listed above and it did solve the problem for me.  My system does resume on battery and AC.  The page in the kernel guide: https://www.kernel.org/doc/html/v4.18/admin-guide/pm/sleep-states.html states that "On ACPI-based systems S2RAM requires some minimal boot-strapping code in the platform firmware to resume the system from it."  I wonder if you have the latest linux-firmware and also if there is a firmware update for you machine that might help?  Or perhaps a microcode update?

Comment 3 Florian 'rephlex' Panzer 2018-10-03 09:30:19 UTC

(In reply to Jason Gambrel from comment #2)
> (In reply to Florian 'rephlex' Panzer from comment #1)
> > Same on an Asus Zenbook UX331UN.
> > 
> > However, this happens if
> > -------
> > # cat /sys/power/mem_sleep
> > [s2idle] deep
> > -------
> > 
> > If you boot with kernel cmdline mem_sleep_default=deep this is issue goes
> > away and the charging state changes as soon as you plug/unplug ac power.
> > 
> > But: If you go to "deep" sleep, the system will ONLY fully resume from
> > standby if you have ac plugged in. If you wake the system up while on
> > battery, the system freezes.
> 
> Thanks for the tip on the kernel cmdline mem_sleep_default=deep.  I tested
> it on my machine listed above and it did solve the problem for me.  My
> system does resume on battery and AC.  The page in the kernel guide:
> https://www.kernel.org/doc/html/v4.18/admin-guide/pm/sleep-states.html
> states that "On ACPI-based systems S2RAM requires some minimal
> boot-strapping code in the platform firmware to resume the system from it." 
> I wonder if you have the latest linux-firmware and also if there is a
> firmware update for you machine that might help?  Or perhaps a microcode
> update?

Both packages are up to date.

rephlex@avis:[~]: apt-cache show intel-microcode | grep Version
Version: 3.20180807a.1
rephlex@avis:[~]: apt-cache show linux-firmware | grep Version
Version: 1.175

It looks like no microcode is loaded when booting:
rephlex@avis:[~]: sudo dmesg | grep microcode
[    1.210619] microcode: sig=0x806ea, pf=0x80, revision=0x96
[    1.210840] microcode: Microcode Update Driver: v2.2.

Furthermore, Latest Asus BIOS Update is installed (v307)

Comment 4 qantas94heavy 2018-11-03 08:55:59 UTC

Running a UX331UA here with exactly the same issue as in comment 1.

Some further information when attempting "deep" sleep:

- If you suspend computer on battery, then plug in AC, resuming will fail.
- If you suspend computer on AC then unplug, it will also fail.

Suspending using all /sys/power/pm_test other than "none" resumes successfully.

Following a failed suspend, dmesg shows the following:

[    3.214842]   Magic number: 6:938:177
[    3.214931] acpi device:0d: hash matches

Running "cat /sys/power/pm_trace_dev_match" gives "acpi".

Runnning "rtcwake –m mem –s 5" attempts to resume after 5 seconds but also fails like a manual resume.

Comment 5 qantas94heavy 2018-11-03 11:30:22 UTC

On further investigation, it seems to be an ACPI/BIOS bug. Not sure whether it would be possible to work around this or not.

The failure to resume also occurs on Windows when forced to use S3 standby mode (using regedit to disable CsEnabled). It seems ASUS only bothered testing "modern standby" on Windows.

Comment 6 Florian 'rephlex' Panzer 2018-11-11 10:38:08 UTC

In the meantime i contacted ASUS and referenced to this issue. My expectations were low to be honest, but they clearly stated they "don't support S3" and connected standby is the way to go.

So this brings us back to the original topic / issue of this bug report:

In s2idle plugging the charger in does nothig (neither light up the charging LED nor actually charge the battery).

Removing the charger will not cause the charging light to go off.

The LED state is preserved from the moment s2idle is entered.

It seems like s2idle powers off the component needed to change the charging state somehow.

Comment 7 Chen Yu 2018-11-13 02:09:43 UTC

The linux only has acpi_ac_resume() and there's no acpi_ac_suspend() implemented, thus s3 might leverage the bios to turn off the light(power off) however since s2idle does not involve BIOS it could not turn them off.
To confirm this, could you please plug the AC, and do the following test:
1. echo deep >  /sys/power/mem_sleep
2. echo core > /sys/power/pm_test
3. echo mem > /sys/power/state   then the system will try to suspend and resume within 5 seconds without entering bios. Please watch the led light if it has ever been turned off during this stage
4. please provide the dmesg

Comment 8 Florian 'rephlex' Panzer 2018-11-13 06:37:16 UTC

(In reply to Chen Yu from comment #7)
> The linux only has acpi_ac_resume() and there's no acpi_ac_suspend()
> implemented, thus s3 might leverage the bios to turn off the light(power
> off) however since s2idle does not involve BIOS it could not turn them off.
> To confirm this, could you please plug the AC, and do the following test:
> 1. echo deep >  /sys/power/mem_sleep
> 2. echo core > /sys/power/pm_test
> 3. echo mem > /sys/power/state   then the system will try to suspend and
> resume within 5 seconds without entering bios. Please watch the led light if
> it has ever been turned off during this stage
> 4. please provide the dmesg


Hi, thank you for looking into this! With The AC connected, i followed the steps.

The light did not turn off during the test, it was turned on constantly. Below is my dmesg:

----- START OF DMESG  
[49561.815053] i2c_hid i2c-ELAN1200:00: i2c_hid_get_input: incomplete report (16/65535)
[49596.561554] PM: suspend entry (deep)
[49596.561558] PM: Syncing filesystems ... done.
[49596.913604] Freezing user space processes ... (elapsed 0.002 seconds) done.
[49596.916115] OOM killer disabled.
[49596.916116] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[49596.917412] Suspending console(s) (use no_console_suspend to debug)
[49597.132878] wlp3s0: deauthenticating from cc:ce:1e:89:51:4b by local choice (Reason: 3=DEAUTH_LEAVING)
[49597.147744] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[49597.154737] sd 2:0:0:0: [sda] Stopping disk
[49597.827769] ACPI: EC: interrupt blocked
[49597.873264] ACPI: Preparing to enter system sleep state S3
[49597.877272] ACPI: EC: event blocked
[49597.877274] ACPI: EC: EC stopped
[49597.877276] PM: Saving platform NVS memory
[49597.877368] Disabling non-boot CPUs ...
[49597.893845] smpboot: CPU 1 is now offline
[49597.917826] smpboot: CPU 2 is now offline
[49597.937788] smpboot: CPU 3 is now offline
[49597.961718] smpboot: CPU 4 is now offline
[49597.984629] IRQ 123: no longer affine to CPU5
[49597.984642] IRQ 128: no longer affine to CPU5
[49597.985667] smpboot: CPU 5 is now offline
[49598.004619] IRQ 124: no longer affine to CPU6
[49598.004633] IRQ 127: no longer affine to CPU6
[49598.005668] smpboot: CPU 6 is now offline
[49598.028601] IRQ 125: no longer affine to CPU7
[49598.028623] IRQ 130: no longer affine to CPU7
[49598.029657] smpboot: CPU 7 is now offline
[49598.036294] PM: suspend debug: Waiting for 5 second(s).
[49602.997299] Enabling non-boot CPUs ...
[49602.997357] x86: Booting SMP configuration:
[49602.997357] smpboot: Booting Node 0 Processor 1 APIC 0x2
[49602.997820]  cache: parent cpu1 should not be sleeping
[49602.997961] CPU1 is up
[49602.998000] smpboot: Booting Node 0 Processor 2 APIC 0x4
[49602.998531]  cache: parent cpu2 should not be sleeping
[49602.998684] CPU2 is up
[49602.998709] smpboot: Booting Node 0 Processor 3 APIC 0x6
[49602.999179]  cache: parent cpu3 should not be sleeping
[49602.999342] CPU3 is up
[49602.999365] smpboot: Booting Node 0 Processor 4 APIC 0x1
[49602.999914]  cache: parent cpu4 should not be sleeping
[49603.000090] CPU4 is up
[49603.000116] smpboot: Booting Node 0 Processor 5 APIC 0x3
[49603.000589]  cache: parent cpu5 should not be sleeping
[49603.000766] CPU5 is up
[49603.000788] smpboot: Booting Node 0 Processor 6 APIC 0x5
[49603.001265]  cache: parent cpu6 should not be sleeping
[49603.001455] CPU6 is up
[49603.001478] smpboot: Booting Node 0 Processor 7 APIC 0x7
[49603.001950]  cache: parent cpu7 should not be sleeping
[49603.002149] CPU7 is up
[49603.009574] ACPI: EC: EC started
[49603.009613] ACPI: Waking up from system sleep state S3
[49603.018377] ACPI: EC: interrupt unblocked
[49603.170689] ACPI: EC: event unblocked
[49603.175036] ACPI: button: The lid device is not compliant to SW_LID.
[49603.181798] sd 2:0:0:0: [sda] Starting disk
[49603.417441] acpi LNXPOWER:01: Turning OFF
[49603.417610] OOM killer enabled.
[49603.417611] Restarting tasks ... done.
[49603.444502] PM: suspend exit
[49603.495281] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[49603.498340] ata3.00: configured for UDMA/133
[49603.502448] ata1: SATA link down (SStatus 4 SControl 300)
[49603.633672] wlp3s0: authenticate with cc:ce:1e:89:51:4c
[49603.645023] wlp3s0: send auth to cc:ce:1e:89:51:4c (try 1/3)
[49603.654470] wlp3s0: authenticated
[49603.658968] wlp3s0: associate with cc:ce:1e:89:51:4c (try 1/3)
[49603.665339] wlp3s0: RX AssocResp from cc:ce:1e:89:51:4c (capab=0x1431 status=0 aid=4)
[49603.668933] wlp3s0: associated
[49603.779099] wlp3s0: Limiting TX power to 20 (20 - 0) dBm as advertised by cc:ce:1e:89:51:4c
----- END OF DMESG

Comment 9 Jason Gambrel 2018-11-14 02:42:25 UTC

(In reply to Chen Yu from comment #7)
> The linux only has acpi_ac_resume() and there's no acpi_ac_suspend()
> implemented, thus s3 might leverage the bios to turn off the light(power
> off) however since s2idle does not involve BIOS it could not turn them off.
> To confirm this, could you please plug the AC, and do the following test:
> 1. echo deep >  /sys/power/mem_sleep
> 2. echo core > /sys/power/pm_test
> 3. echo mem > /sys/power/state   then the system will try to suspend and
> resume within 5 seconds without entering bios. Please watch the led light if
> it has ever been turned off during this stage
> 4. please provide the dmesg

I am not certain if I did this correctly.  I rebooted to recovery mode in Mint and dropped to root shell prompt.  I entered the above 3 commands.  The screen went empty except for a cursor for about 5 seconds and the power led did not turn off.  I then repeated the test with the same results.  Here is the dmesg log:

[  114.655630] PM: suspend entry (deep)
[  114.655630] PM: Syncing filesystems ... done.
[  114.724985] Freezing user space processes ... (elapsed 0.007 seconds) done.
[  114.732392] OOM killer disabled.
[  114.732392] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[  114.733614] Suspending console(s) (use no_console_suspend to debug)
[  114.858035] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[  114.862690] sd 2:0:0:0: [sda] Stopping disk
[  115.127324] ACPI: EC: interrupt blocked
[  115.170281] ACPI: Preparing to enter system sleep state S3
[  115.173236] ACPI: EC: event blocked
[  115.173237] ACPI: EC: EC stopped
[  115.173237] PM: Saving platform NVS memory
[  115.173242] Disabling non-boot CPUs ...
[  115.187219] smpboot: CPU 1 is now offline
[  115.223462] smpboot: CPU 2 is now offline
[  115.243215] smpboot: CPU 3 is now offline
[  115.259205] smpboot: CPU 4 is now offline
[  115.275183] smpboot: CPU 5 is now offline
[  115.307193] smpboot: CPU 6 is now offline
[  115.323164] smpboot: CPU 7 is now offline
[  115.324699] PM: suspend debug: Waiting for 5 second(s).
[  120.285638] Enabling non-boot CPUs ...
[  120.285678] x86: Booting SMP configuration:
[  120.285679] smpboot: Booting Node 0 Processor 1 APIC 0x2
[  120.286148]  cache: parent cpu1 should not be sleeping
[  120.286267] CPU1 is up
[  120.286305] smpboot: Booting Node 0 Processor 2 APIC 0x4
[  120.286799]  cache: parent cpu2 should not be sleeping
[  120.286929] CPU2 is up
[  120.286950] smpboot: Booting Node 0 Processor 3 APIC 0x6
[  120.287409]  cache: parent cpu3 should not be sleeping
[  120.287564] CPU3 is up
[  120.287586] smpboot: Booting Node 0 Processor 4 APIC 0x1
[  120.288120]  cache: parent cpu4 should not be sleeping
[  120.288273] CPU4 is up
[  120.288298] smpboot: Booting Node 0 Processor 5 APIC 0x3
[  120.288748]  cache: parent cpu5 should not be sleeping
[  120.288897] CPU5 is up
[  120.288916] smpboot: Booting Node 0 Processor 6 APIC 0x5
[  120.289368]  cache: parent cpu6 should not be sleeping
[  120.289523] CPU6 is up
[  120.289543] smpboot: Booting Node 0 Processor 7 APIC 0x7
[  120.290000]  cache: parent cpu7 should not be sleeping
[  120.290165] CPU7 is up
[  120.296892] ACPI: EC: EC started
[  120.296899] ACPI: Waking up from system sleep state S3
[  120.306017] ACPI: EC: interrupt unblocked
[  120.347817] ACPI: EC: event unblocked
[  120.349005] ACPI: button: The lid device is not compliant to SW_LID.
[  120.358026] sd 2:0:0:0: [sda] Starting disk
[  120.521750] acpi LNXPOWER:13: Turning OFF
[  120.521803] acpi LNXPOWER:12: Turning OFF
[  120.521853] acpi LNXPOWER:11: Turning OFF
[  120.521904] acpi LNXPOWER:10: Turning OFF
[  120.521953] acpi LNXPOWER:0f: Turning OFF
[  120.522002] acpi LNXPOWER:0e: Turning OFF
[  120.522052] acpi LNXPOWER:0d: Turning OFF
[  120.522101] acpi LNXPOWER:0c: Turning OFF
[  120.522151] acpi LNXPOWER:0b: Turning OFF
[  120.522200] acpi LNXPOWER:0a: Turning OFF
[  120.522250] acpi LNXPOWER:09: Turning OFF
[  120.522299] acpi LNXPOWER:08: Turning OFF
[  120.522349] acpi LNXPOWER:07: Turning OFF
[  120.522398] acpi LNXPOWER:06: Turning OFF
[  120.522447] acpi LNXPOWER:05: Turning OFF
[  120.522499] acpi LNXPOWER:04: Turning OFF
[  120.522550] acpi LNXPOWER:03: Turning OFF
[  120.522598] acpi LNXPOWER:02: Turning OFF
[  120.522647] acpi LNXPOWER:01: Turning OFF
[  120.522695] acpi LNXPOWER:00: Turning OFF
[  120.522727] OOM killer enabled.
[  120.522728] Restarting tasks ... done.
[  120.523803] thermal thermal_zone6: failed to read out thermal zone (-61)
[  120.532972] PM: suspend exit
[  120.672329] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[  120.676219] ata3.00: configured for UDMA/133
[  129.448769] PM: suspend entry (deep)
[  129.448770] PM: Syncing filesystems ... done.
[  129.523311] Freezing user space processes ... (elapsed 0.000 seconds) done.
[  129.524268] OOM killer disabled.
[  129.524268] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[  129.525506] Suspending console(s) (use no_console_suspend to debug)
[  129.648227] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[  129.652933] sd 2:0:0:0: [sda] Stopping disk
[  129.873712] ACPI: EC: interrupt blocked
[  129.916424] ACPI: Preparing to enter system sleep state S3
[  129.918536] ACPI: EC: event blocked
[  129.918537] ACPI: EC: EC stopped
[  129.918537] PM: Saving platform NVS memory
[  129.918542] Disabling non-boot CPUs ...
[  129.933348] smpboot: CPU 1 is now offline
[  129.949367] smpboot: CPU 2 is now offline
[  129.965338] smpboot: CPU 3 is now offline
[  129.981570] smpboot: CPU 4 is now offline
[  129.997293] smpboot: CPU 5 is now offline
[  130.021299] smpboot: CPU 6 is now offline
[  130.041297] smpboot: CPU 7 is now offline
[  130.042744] PM: suspend debug: Waiting for 5 second(s).
[  135.003668] Enabling non-boot CPUs ...
[  135.003731] x86: Booting SMP configuration:
[  135.003732] smpboot: Booting Node 0 Processor 1 APIC 0x2
[  135.004213]  cache: parent cpu1 should not be sleeping
[  135.004332] CPU1 is up
[  135.004371] smpboot: Booting Node 0 Processor 2 APIC 0x4
[  135.004880]  cache: parent cpu2 should not be sleeping
[  135.005010] CPU2 is up
[  135.005030] smpboot: Booting Node 0 Processor 3 APIC 0x6
[  135.005545]  cache: parent cpu3 should not be sleeping
[  135.005689] CPU3 is up
[  135.005710] smpboot: Booting Node 0 Processor 4 APIC 0x1
[  135.006291]  cache: parent cpu4 should not be sleeping
[  135.006435] CPU4 is up
[  135.006458] smpboot: Booting Node 0 Processor 5 APIC 0x3
[  135.006924]  cache: parent cpu5 should not be sleeping
[  135.007069] CPU5 is up
[  135.007089] smpboot: Booting Node 0 Processor 6 APIC 0x5
[  135.007558]  cache: parent cpu6 should not be sleeping
[  135.007712] CPU6 is up
[  135.007733] smpboot: Booting Node 0 Processor 7 APIC 0x7
[  135.008203]  cache: parent cpu7 should not be sleeping
[  135.008374] CPU7 is up
[  135.015119] ACPI: EC: EC started
[  135.015125] ACPI: Waking up from system sleep state S3
[  135.024203] ACPI: EC: interrupt unblocked
[  135.065919] ACPI: EC: event unblocked
[  135.076179] sd 2:0:0:0: [sda] Starting disk
[  135.243358] acpi LNXPOWER:13: Turning OFF
[  135.243410] acpi LNXPOWER:12: Turning OFF
[  135.243460] acpi LNXPOWER:11: Turning OFF
[  135.243510] acpi LNXPOWER:10: Turning OFF
[  135.243559] acpi LNXPOWER:0f: Turning OFF
[  135.243608] acpi LNXPOWER:0e: Turning OFF
[  135.243657] acpi LNXPOWER:0d: Turning OFF
[  135.243719] acpi LNXPOWER:0c: Turning OFF
[  135.243768] acpi LNXPOWER:0b: Turning OFF
[  135.243817] acpi LNXPOWER:0a: Turning OFF
[  135.243866] acpi LNXPOWER:09: Turning OFF
[  135.243915] acpi LNXPOWER:08: Turning OFF
[  135.243964] acpi LNXPOWER:07: Turning OFF
[  135.244013] acpi LNXPOWER:06: Turning OFF
[  135.244062] acpi LNXPOWER:05: Turning OFF
[  135.244111] acpi LNXPOWER:04: Turning OFF
[  135.244160] acpi LNXPOWER:03: Turning OFF
[  135.244209] acpi LNXPOWER:02: Turning OFF
[  135.244257] acpi LNXPOWER:01: Turning OFF
[  135.244305] acpi LNXPOWER:00: Turning OFF
[  135.244339] OOM killer enabled.
[  135.244340] Restarting tasks ... done.
[  135.245714] thermal thermal_zone6: failed to read out thermal zone (-61)
[  135.257153] PM: suspend exit
[  135.386456] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[  135.390575] ata3.00: configured for UDMA/133

Comment 10 Jason Gambrel 2018-11-14 03:13:25 UTC

(In reply to Chen Yu from comment #7)
> The linux only has acpi_ac_resume() and there's no acpi_ac_suspend()
> implemented, thus s3 might leverage the bios to turn off the light(power
> off) however since s2idle does not involve BIOS it could not turn them off.
> To confirm this, could you please plug the AC, and do the following test:
> 1. echo deep >  /sys/power/mem_sleep
> 2. echo core > /sys/power/pm_test
> 3. echo mem > /sys/power/state   then the system will try to suspend and
> resume within 5 seconds without entering bios. Please watch the led light if
> it has ever been turned off during this stage
> 4. please provide the dmesg

My apologies.  I noticed the AC adapter was not plugged into the wall on that last attempt.  The LED I noted was the power on LED.  I repeated the test, entering the above commands.  The charging LED remained red throughout the test indicating charging.  The power LED remained white throughout the test and the screen displayed a cursor with no text throughout the test.  Dmesg log:

[   69.844575] PM: suspend entry (deep)
[   69.844575] PM: Syncing filesystems ... done.
[   69.853611] Freezing user space processes ... (elapsed 0.001 seconds) done.
[   69.854820] OOM killer disabled.
[   69.854820] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[   69.856017] Suspending console(s) (use no_console_suspend to debug)
[   69.992066] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[   69.996800] sd 2:0:0:0: [sda] Stopping disk
[   70.235276] ACPI: EC: interrupt blocked
[   70.276302] ACPI: Preparing to enter system sleep state S3
[   70.278423] ACPI: EC: event blocked
[   70.278423] ACPI: EC: EC stopped
[   70.278424] PM: Saving platform NVS memory
[   70.278429] Disabling non-boot CPUs ...
[   70.293489] smpboot: CPU 1 is now offline
[   70.317220] smpboot: CPU 2 is now offline
[   70.341232] smpboot: CPU 3 is now offline
[   70.365215] smpboot: CPU 4 is now offline
[   70.389216] smpboot: CPU 5 is now offline
[   70.413182] smpboot: CPU 6 is now offline
[   70.437180] smpboot: CPU 7 is now offline
[   70.438705] PM: suspend debug: Waiting for 5 second(s).
[   75.399630] Enabling non-boot CPUs ...
[   75.399667] x86: Booting SMP configuration:
[   75.399667] smpboot: Booting Node 0 Processor 1 APIC 0x2
[   75.400120]  cache: parent cpu1 should not be sleeping
[   75.400244] CPU1 is up
[   75.400287] smpboot: Booting Node 0 Processor 2 APIC 0x4
[   75.400770]  cache: parent cpu2 should not be sleeping
[   75.400906] CPU2 is up
[   75.400931] smpboot: Booting Node 0 Processor 3 APIC 0x6
[   75.401361]  cache: parent cpu3 should not be sleeping
[   75.401500] CPU3 is up
[   75.401524] smpboot: Booting Node 0 Processor 4 APIC 0x1
[   75.402030]  cache: parent cpu4 should not be sleeping
[   75.402185] CPU4 is up
[   75.402213] smpboot: Booting Node 0 Processor 5 APIC 0x3
[   75.402654]  cache: parent cpu5 should not be sleeping
[   75.402805] CPU5 is up
[   75.402829] smpboot: Booting Node 0 Processor 6 APIC 0x5
[   75.403297]  cache: parent cpu6 should not be sleeping
[   75.403456] CPU6 is up
[   75.403477] smpboot: Booting Node 0 Processor 7 APIC 0x7
[   75.403932]  cache: parent cpu7 should not be sleeping
[   75.404100] CPU7 is up
[   75.411035] ACPI: EC: EC started
[   75.411043] ACPI: Waking up from system sleep state S3
[   75.419737] ACPI: EC: interrupt unblocked
[   75.461839] ACPI: EC: event unblocked
[   75.463495] ACPI: button: The lid device is not compliant to SW_LID.
[   75.472181] sd 2:0:0:0: [sda] Starting disk
[   75.635491] acpi LNXPOWER:13: Turning OFF
[   75.635544] acpi LNXPOWER:12: Turning OFF
[   75.635595] acpi LNXPOWER:11: Turning OFF
[   75.635647] acpi LNXPOWER:10: Turning OFF
[   75.635697] acpi LNXPOWER:0f: Turning OFF
[   75.635747] acpi LNXPOWER:0e: Turning OFF
[   75.635797] acpi LNXPOWER:0d: Turning OFF
[   75.635849] acpi LNXPOWER:0c: Turning OFF
[   75.635899] acpi LNXPOWER:0b: Turning OFF
[   75.635949] acpi LNXPOWER:0a: Turning OFF
[   75.635999] acpi LNXPOWER:09: Turning OFF
[   75.636049] acpi LNXPOWER:08: Turning OFF
[   75.636098] acpi LNXPOWER:07: Turning OFF
[   75.636148] acpi LNXPOWER:06: Turning OFF
[   75.636199] acpi LNXPOWER:05: Turning OFF
[   75.636248] acpi LNXPOWER:04: Turning OFF
[   75.636299] acpi LNXPOWER:03: Turning OFF
[   75.636348] acpi LNXPOWER:02: Turning OFF
[   75.636398] acpi LNXPOWER:01: Turning OFF
[   75.636448] acpi LNXPOWER:00: Turning OFF
[   75.636484] OOM killer enabled.
[   75.636484] Restarting tasks ... done.
[   75.637759] thermal thermal_zone6: failed to read out thermal zone (-61)
[   75.656467] PM: suspend exit
[   75.786320] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   75.790151] ata3.00: configured for UDMA/133

Comment 11 Florian 'rephlex' Panzer 2018-11-14 06:42:29 UTC

> he charging LED remained red throughout the
>test indicating charging.  The power LED
> remained white throughout the test and t

For those testing and without Asus laptop at hand:

Red charging led = Battery not full, charging

Constant white power LED = power on (blinking would be standby)

My ux331ua did the same during the test.

Comment 12 Henry Iguaro 2018-12-01 09:11:09 UTC

Hi.

I have a brand new Asus Zenbook UX331UN running Linux Mint 19 Tara with this same issue.

First I noticed the big power drop when putting the laptop in sleep mode and resuming after an hour, then I followed Rephlex's blog instructions to enable 'deep' sleep (https://rephlex.de/blog/2018/08/21/asus-zenbook-13-ux331un-with-ubuntu-battery-drain-while-in-suspend/) and now the laptop does not resume when is on battery.

Things I tried:
* Sleep on AC power adapter plugged in, unplug the adapter, try to resume [failed].
* Sleep on AC power adapter plugged in, unplug the adapter, plug it back again, try to resume [failed].
* Sleep battery, plug the adapter, try to resume [failed].

Following the instructions from Chen Yu, I got the following from dmesg:

[ 4685.083799] [UFW BLOCK] IN=wlp3s0 OUT= MAC=94:b8:6d:83:94:5b:a4:77:33:4c:fd:50:08:00 SRC=192.168.1.2 DST=192.168.1.16 LEN=543 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=33373 DPT=38050 LEN=523 
[ 4758.437089] PM: suspend entry (deep)
[ 4758.437092] PM: Syncing filesystems ... done.
[ 4758.983708] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 4758.985383] OOM killer disabled.
[ 4758.985384] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 4758.986549] Suspending console(s) (use no_console_suspend to debug)
[ 4759.202272] wlp3s0: deauthenticating from 00:60:64:a5:9b:be by local choice (Reason: 3=DEAUTH_LEAVING)
[ 4759.217628] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[ 4759.217835] sd 2:0:0:0: [sda] Stopping disk
[ 4759.522770] ACPI: EC: interrupt blocked
[ 4759.572637] ACPI: Preparing to enter system sleep state S3
[ 4759.576217] ACPI: EC: event blocked
[ 4759.576218] ACPI: EC: EC stopped
[ 4759.576219] PM: Saving platform NVS memory
[ 4759.576299] Disabling non-boot CPUs ...
[ 4759.591380] smpboot: CPU 1 is now offline
[ 4759.623394] smpboot: CPU 2 is now offline
[ 4759.643291] smpboot: CPU 3 is now offline
[ 4759.666211] IRQ 127: no longer affine to CPU4
[ 4759.668364] smpboot: CPU 4 is now offline
[ 4759.690117] IRQ 125: no longer affine to CPU5
[ 4759.690135] IRQ 128: no longer affine to CPU5
[ 4759.691157] smpboot: CPU 5 is now offline
[ 4759.714092] IRQ 123: no longer affine to CPU6
[ 4759.714116] IRQ 132: no longer affine to CPU6
[ 4759.715137] smpboot: CPU 6 is now offline
[ 4759.738049] IRQ 122: no longer affine to CPU7
[ 4759.738081] IRQ 130: no longer affine to CPU7
[ 4759.739114] smpboot: CPU 7 is now offline
[ 4759.740931] PM: suspend debug: Waiting for 5 second(s).
[ 4764.701998] Enabling non-boot CPUs ...
[ 4764.702039] x86: Booting SMP configuration:
[ 4764.702039] smpboot: Booting Node 0 Processor 1 APIC 0x2
[ 4764.702476]  cache: parent cpu1 should not be sleeping
[ 4764.702613] CPU1 is up
[ 4764.702654] smpboot: Booting Node 0 Processor 2 APIC 0x4
[ 4764.703144]  cache: parent cpu2 should not be sleeping
[ 4764.703298] CPU2 is up
[ 4764.703321] smpboot: Booting Node 0 Processor 3 APIC 0x6
[ 4764.703767]  cache: parent cpu3 should not be sleeping
[ 4764.703932] CPU3 is up
[ 4764.703956] smpboot: Booting Node 0 Processor 4 APIC 0x1
[ 4764.704494]  cache: parent cpu4 should not be sleeping
[ 4764.704663] CPU4 is up
[ 4764.704686] smpboot: Booting Node 0 Processor 5 APIC 0x3
[ 4764.705117]  cache: parent cpu5 should not be sleeping
[ 4764.705291] CPU5 is up
[ 4764.705315] smpboot: Booting Node 0 Processor 6 APIC 0x5
[ 4764.705749]  cache: parent cpu6 should not be sleeping
[ 4764.705935] CPU6 is up
[ 4764.705959] smpboot: Booting Node 0 Processor 7 APIC 0x7
[ 4764.706398]  cache: parent cpu7 should not be sleeping
[ 4764.706599] CPU7 is up
[ 4764.713776] ACPI: EC: EC started
[ 4764.713817] ACPI: Waking up from system sleep state S3
[ 4764.721859] ACPI: EC: interrupt unblocked
[ 4764.875818] ACPI: EC: event unblocked
[ 4764.878532] sd 2:0:0:0: [sda] Starting disk
[ 4764.880886] rtc_cmos 00:01: Alarms can be up to one month in the future
[ 4765.196496] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 4765.199622] ata3.00: configured for UDMA/133
[ 4765.199707] ata3.00: Enabling discard_zeroes_data
[ 4765.223039] OOM killer enabled.
[ 4765.223040] Restarting tasks ... done.
[ 4765.253602] PM: suspend exit
[ 4766.643740] [drm] RC6 on
[ 4768.617355] wlp3s0: authenticate with 00:60:64:a5:9b:be
[ 4768.627631] wlp3s0: send auth to 00:60:64:a5:9b:be (try 1/3)
[ 4768.636829] wlp3s0: authenticated
[ 4768.639570] wlp3s0: associate with 00:60:64:a5:9b:be (try 1/3)
[ 4768.646206] wlp3s0: RX AssocResp from 00:60:64:a5:9b:be (capab=0x411 status=0 aid=8)
[ 4768.649757] wlp3s0: associated
[ 4770.276867] [UFW BLOCK] IN=wlp3s0 OUT= MAC=94:b8:6d:83:94:5b:38:8b:59:1c:c6:b7:08:00 SRC=192.168.1.19 DST=192.168.1.16 LEN=543 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=47573 DPT=33058 LEN=523 
[ 4771.299677] [UFW BLOCK] IN=wlp3s0 OUT= MAC=94:b8:6d:83:94:5b:a4:77:33:4c:fd:50:08:00 SRC=192.168.1.2 DST=192.168.1.16 LEN=543 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=58425 DPT=33058 LEN=523 
[ 4771.304924] [UFW BLOCK] IN=wlp3s0 OUT= MAC=94:b8:6d:83:94:5b:38:8b:59:1c:c6:b7:08:00 SRC=192.168.1.19 DST=192.168.1.16 LEN=543 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=59445 DPT=33058 LEN=523 
[ 4772.323837] [UFW BLOCK] IN=wlp3s0 OUT= MAC=94:b8:6d:83:94:5b:a4:77:33:4c:fd:50:08:00 SRC=192.168.1.2 DST=192.168.1.16 LEN=543 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=47342 DPT=33058 LEN=523 

The led light was ON (didn't blink though) in all my tests.

Comment 13 Zhang Rui 2018-12-03 03:54:32 UTC

Hi, Henry,
what kernel version are you using? and please confirm if the problem still exists in the latest upstream kernel.

Comment 14 Florian 'rephlex' Panzer 2018-12-03 09:24:26 UTC

Still exists in UX331UN Firmware Version 307 (latest) and Kernel 4.20.0-042000rc5-generic #201812021930

Comment 15 Henry Iguaro 2018-12-06 13:45:46 UTC

Hi Zhang,

The kernel version is 4.15.0-42-generic. 

I switched to the latest upstream kernel (4.20.0-042000rc5-generic) and (as Florian 'rephlex' Panzer pointed out) the issue remains. 

Is there any other information that you may need?

Comment 16 Florian 'rephlex' Panzer 2019-01-01 15:40:15 UTC

just an update, problem still reproduceable in 4.20

Comment 17 Florian 'rephlex' Panzer 2019-02-24 08:08:52 UTC

Just checking back, the status of this bug is NEEDINFO.
What additional information should be provided?

Comment 18 Zhang Rui 2019-03-26 08:43:02 UTC

Seems we have multiple bug reporter here.
To be clear, let's focus on the original issue ONLY here.
So the problem is that:
machine will not charge if the charger is plugged in after s2idle, and we don't have the issue for S3, right?

Comment 19 Carsten Otto 2019-03-26 09:27:48 UTC

@Zhang Rui: Exactly.

To clarify/reword:
With S3:
Charging works as expected (but there are wakeup issues).

With s2idle, after suspending:
The laptop does not charge when the cable is plugged in.
The LED does not change when the cable is plugged in.
The LED still indicates charging (amber) when the cable is removed (but was plugged in before suspending).

Comment 20 Florian 'rephlex' Panzer 2019-03-26 10:06:05 UTC

(In reply to Carsten Otto from comment #19)
> @Zhang Rui: Exactly.
> 
> To clarify/reword:
> With S3:
> Charging works as expected (but there are wakeup issues).
> 
> With s2idle, after suspending:
> The laptop does not charge when the cable is plugged in.
> The LED does not change when the cable is plugged in.
> The LED still indicates charging (amber) when the cable is removed (but was
> plugged in before suspending).


Absolutely correct in every aspect.

Comment 21 Florian 'rephlex' Panzer 2019-05-17 11:19:05 UTC

jfyi: issue still present in Kernel 5.1.3.

Comment 22 Kristian Klausen 2019-08-15 21:13:45 UTC

I have the same issue with a Zenbook UX430UNR, so I assume it affect most newer ASUS laptops.

Tested with 5.2.8-arch1-1-ARCH and http://git.infradead.org/linux-platform-drivers-x86.git/commit/e3168b874321d04c160c9eb937919eb926ae232f

Comment 23 Kristian Klausen 2019-08-15 23:03:32 UTC

(In reply to Kristian Klausen from comment #22)
> I have the same issue with a Zenbook UX430UNR, so I assume it affect most
> newer ASUS laptops.
> 
> Tested with 5.2.8-arch1-1-ARCH and
> http://git.infradead.org/linux-platform-drivers-x86.git/commit/
> e3168b874321d04c160c9eb937919eb926ae232f

I did notice that in Windows plugging or unplugging power adapter wakes the laptop from suspend if the lid is open. That doesn't happen in Linux.

I assume the battery circuit is incorrectly powered off?

Comment 24 Zhang Rui 2019-09-03 06:44:54 UTC

(In reply to Kristian Klausen from comment #23)
> (In reply to Kristian Klausen from comment #22)
> > I have the same issue with a Zenbook UX430UNR, so I assume it affect most
> > newer ASUS laptops.
> > 
> > Tested with 5.2.8-arch1-1-ARCH and
> > http://git.infradead.org/linux-platform-drivers-x86.git/commit/
> > e3168b874321d04c160c9eb937919eb926ae232f
> 
> I did notice that in Windows plugging or unplugging power adapter wakes the
> laptop from suspend if the lid is open. That doesn't happen in Linux.
> 
this is a good hint, so I guess the above issue only happens with lid opened? This sounds right, as we can check LED only with Lid opened.

So another question,
> The laptop does not charge when the cable is plugged in.
how do you observe this? check battery status, enter s2idle with lid opened, and then plug the cable in, and wait for a few hours and recheck the battery status?
if yes, it's better to check if windows can charge with Lid opened or not.

Comment 25 Carsten Otto 2019-09-03 06:49:44 UTC

Zhang, on the UX331UN the charging indicator LED is at the side, so you can see it with the lid closed. Furthermore, I also tried to charge by plugging in the cable AFTER suspending the laptop. In all those cases the laptop was NOT charged.

Comment 26 Florian 'rephlex' Panzer 2019-09-03 07:20:22 UTC

Full ACK to Carsten Otto 2019-09-03 06:49:44 UTC.

The Message from Kristian Klausen 2019-08-15 23:03:32 UTC is not really related to the issue.

Comment 27 Kristian Klausen 2019-09-03 08:06:03 UTC

(In reply to Zhang Rui from comment #24)
> (In reply to Kristian Klausen from comment #23)
> > (In reply to Kristian Klausen from comment #22)
> > > I have the same issue with a Zenbook UX430UNR, so I assume it affect most
> > > newer ASUS laptops.
> > > 
> > > Tested with 5.2.8-arch1-1-ARCH and
> > > http://git.infradead.org/linux-platform-drivers-x86.git/commit/
> > > e3168b874321d04c160c9eb937919eb926ae232f
> > 
> > I did notice that in Windows plugging or unplugging power adapter wakes the
> > laptop from suspend if the lid is open. That doesn't happen in Linux.
> > 
> this is a good hint, so I guess the above issue only happens with lid
> opened? This sounds right, as we can check LED only with Lid opened.

If the lid is opened or not does not affect the issue. The LED is on the side, so they lid does not need to be opened.

> So another question,
> > The laptop does not charge when the cable is plugged in.
> how do you observe this? check battery status, enter s2idle with lid opened,
> and then plug the cable in, and wait for a few hours and recheck the battery
> status?

The laptop was plugged in overnight, but the battery capacity was the same next morning.

> if yes, it's better to check if windows can charge with Lid opened or not.

I find it very unlikely that charging isn't working in Windows.

Comment 28 Kristian Klausen 2019-09-03 08:10:45 UTC

(In reply to Florian 'rephlex' Panzer from comment #26)
> Full ACK to Carsten Otto 2019-09-03 06:49:44 UTC.
> 
> The Message from Kristian Klausen 2019-08-15 23:03:32 UTC is not really
> related to the issue.

What do you mean? The laptop won't charge, isn't that the scope of this issue?

Comment 29 Zhang Rui 2019-09-03 13:19:41 UTC

(In reply to Carsten Otto from comment #19)
> @Zhang Rui: Exactly.
> 
> To clarify/reword:
> With S3:
> Charging works as expected (but there are wakeup issues).
> 
> With s2idle, after suspending:
> The laptop does not charge when the cable is plugged in.
> The LED does not change when the cable is plugged in.
> The LED still indicates charging (amber) when the cable is removed (but was
> plugged in before suspending).

does all the three symptom go away after you resume the system back? or it keeps as it is when suspended.

Comment 30 Carsten Otto 2019-09-03 13:59:31 UTC

Yes, the symptoms go away. After resuming everything is as expected, I don't need to do anything.

Comment 31 Zhang Rui 2019-09-04 00:55:09 UTC

then one possibility is that we have a charger driver in Linux kernel. The charger driver does not make it a wakeup device, thus it can not respond to any interrupt during s2idle.
problem is I don't know what charger driver is used, say, who is responsible for handling the charger LED on this platform.

let's do some test here.

after boot, at runtime,
get the full dmesg output and acpidump output, and then unplug the AC adapter, run
"cat /proc/interrupts > interrupt-before-plug.log ; grep . /sys/firmware/acpi/interrupts/* > acpi-interrupt-before-plug.log; grep . /sys/class/power_supply/*/* > power-supply-before-plug.log"
and then plug in the AC adapter, run
"cat /proc/interrupts > interrupt-after-plug.log ; grep . /sys/firmware/acpi/interrupts/* > acpi-interrupt-after-plug.log; grep . /sys/class/power_supply/*/* > power-supply-after-plug.log"
and then unplug the AC adapter, run
"cat /proc/interrupts > interrupt-after-unplug.log ; grep . /sys/firmware/acpi/interrupts/* > acpi-interrupt-after-unplug.log; grep . /sys/class/power_supply/*/* > power-supply-after-unplug.log"

please attach dmesg, acpidump, and the 9 log files here.

Hopefully we can figure out what driver is used on this platform to handle the charger device.

Comment 32 Carsten Otto 2019-09-04 15:20:05 UTC

Created attachment 284819 [details]
dmesg, cable plugged in, very first step

Comment 33 Carsten Otto 2019-09-04 15:20:34 UTC

Created attachment 284821 [details]
dmesg, cable unplugged, very last step

Comment 34 Carsten Otto 2019-09-04 15:20:50 UTC

Created attachment 284823 [details]
acpidump

Comment 35 Carsten Otto 2019-09-04 15:21:20 UTC

Created attachment 284825 [details]
acpi-interrupt-after-plug

Comment 36 Carsten Otto 2019-09-04 15:21:32 UTC

Created attachment 284827 [details]
acpi-interrupt-after-unplug

Comment 37 Carsten Otto 2019-09-04 15:21:44 UTC

Created attachment 284829 [details]
acpi-interrupt-before-plug

Comment 38 Carsten Otto 2019-09-04 15:22:17 UTC

Created attachment 284831 [details]
interrupt-after-plug

Comment 39 Carsten Otto 2019-09-04 15:22:32 UTC

Created attachment 284833 [details]
interrupt-after-unplug

Comment 40 Carsten Otto 2019-09-04 15:22:47 UTC

Created attachment 284835 [details]
interrupt-before-plug

Comment 41 Carsten Otto 2019-09-04 15:23:03 UTC

Created attachment 284837 [details]
power-supply-after-plug

Comment 42 Carsten Otto 2019-09-04 15:23:19 UTC

Created attachment 284839 [details]
power-supply-after-unplug

Comment 43 Carsten Otto 2019-09-04 15:23:34 UTC

Created attachment 284841 [details]
power-supply-before-plug

Comment 44 Carsten Otto 2019-09-04 15:24:31 UTC

(In reply to Zhang Rui from comment #31)
> please attach dmesg, acpidump, and the 9 log files here.

I did that. Feel free to ask for more :) Thanks

Comment 45 Zhang Rui 2019-09-29 07:48:25 UTC

Well, I see EC interrupts when plugging/unplugging the AC adapter, so EC is probably handling this.

please run
echo 1 > /sys/modules/acpi/paramters/sleep_no_lps0
before suspend and check if the problem still exists.

Comment 46 Carsten Otto 2019-09-29 21:10:11 UTC

(In reply to Zhang Rui from comment #45)

Thank you a lot, I will do that. Just to make sure, this is not in any released kernel, right? I'm on v5.2 now, and according to git this isn't even in v5.3. I'll compile (and run) from master soon-ish and see if that helps.

Comment 47 Carsten Otto 2019-09-30 21:05:03 UTC

(In reply to Zhang Rui from comment #45)
> echo 1 > /sys/modules/acpi/paramters/sleep_no_lps0


I did:
echo 1 > /sys/module/acpi/parameters/sleep_no_lps0

When I send the laptop into standby, the power LED usually flashes. After this change, it stays on.

Standby seems to work as intended (I can't hear the fan, network is down, "while true; date; sleep 1; done" doesn't update.

When I attach the power cable AFTER suspend the LED now indicates that the laptop is charging. It looks like this is a fix for this issue. I'll update this issue if I notice any other changes.

Comment 48 fp 2019-10-01 16:21:00 UTC

Am 29.09.19 um 09:48 schrieb bugzilla-daemon@bugzilla.kernel.org:
> https://bugzilla.kernel.org/show_bug.cgi?id=201307
> 
> --- Comment #45 from Zhang Rui (rui.zhang@intel.com) ---
> Well, I see EC interrupts when plugging/unplugging the AC adapter, so EC is
> probably handling this.
> 
> please run
> echo 1 > /sys/modules/acpi/paramters/sleep_no_lps0
> before suspend and check if the problem still exists.
> 

Here, sleep_no_lps0 doesn't exist.

Linux avis 5.3.1-050301-generic #201909210632 SMP Sat Sep 21 06:34:27 
UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

BIOS: UX331UN.308

root@avis:/sys/module/acpi# ls -1 /sys/module/acpi/parameters/
acpica_version
aml_debug_output
debug_layer
debug_level
ec_busy_polling
ec_delay
ec_event_clearing
ec_freeze_events
ec_max_queries
ec_no_wakeup
ec_polling_guard
ec_storm_threshold
immediate_undock
trace_debug_layer
trace_debug_level
trace_method_name
trace_state

Comment 49 Carsten Otto 2019-10-01 16:50:27 UTC

(In reply to fp from comment #48)
> Here, sleep_no_lps0 doesn't exist.

I had to compile the kernel from the master branch. It is not part of any released kernel, as far as I know.

Comment 50 Kristian Klausen 2019-10-01 17:56:06 UTC

(In reply to Carsten Otto from comment #47)
> (In reply to Zhang Rui from comment #45)
> > echo 1 > /sys/modules/acpi/paramters/sleep_no_lps0
> 
> 
> I did:
> echo 1 > /sys/module/acpi/parameters/sleep_no_lps0
> 
> When I send the laptop into standby, the power LED usually flashes. After
> this change, it stays on.
> 
> Standby seems to work as intended (I can't hear the fan, network is down,
> "while true; date; sleep 1; done" doesn't update.
> 
> When I attach the power cable AFTER suspend the LED now indicates that the
> laptop is charging. It looks like this is a fix for this issue. I'll update
> this issue if I notice any other changes.

I don't think the issue is fixed if the power LED isn't flashing. Do you have a power meter on hand, so you could measure the power draw?

If not: Could you run cat /sys/class/power_supply/BAT0/energy_now, suspend for 5 minute and run cat /sys/class/power_supply/BAT0/energy_now again.

Then subtract the two values, multiply it with 12 and divide it with 1000000, then you have the power draw in watt-hour.

(In reply to Carsten Otto from comment #49)
> (In reply to fp from comment #48)
> > Here, sleep_no_lps0 doesn't exist.
> 
> I had to compile the kernel from the master branch. It is not part of any
> released kernel, as far as I know.

It was added in 5.4-rc1.

Comment 51 Carsten Otto 2019-10-20 13:24:52 UTC

(In reply to Kristian Klausen from comment #50)
> If not: Could you run cat /sys/class/power_supply/BAT0/energy_now, suspend
> for 5 minute and run cat /sys/class/power_supply/BAT0/energy_now again.
> 
> Then subtract the two values, multiply it with 12 and divide it with
> 1000000, then you have the power draw in watt-hour.


Sorry for the delay. I did that with the kernel default and with sleep_no_lps0=1, around 5 minutes each, adjusted the results based on the actual number of seconds.

Kernel default: 1.340
sleep_no_lps0:  1.706

So, I think you're right. That didn't really fix anything :)

Comment 52 Zhang Rui 2020-06-29 07:41:24 UTC

can you please try the latest upstream kernel and see if the problem has been fixed or not?
we have made quite some EC changes recently and hopefully it can fix the problem for you.

Comment 53 Kristian Klausen 2020-06-29 14:31:35 UTC

(In reply to Zhang Rui from comment #52)
> can you please try the latest upstream kernel and see if the problem has
> been fixed or not?
> we have made quite some EC changes recently and hopefully it can fix the
> problem for you.

I'm running 5.7.4-arch1-1 and the issue is still present. Should I try the mainline kernel (5.8)?

Comment 54 Kristian Klausen 2020-06-29 15:06:56 UTC

(In reply to Kristian Klausen from comment #53)
> (In reply to Zhang Rui from comment #52)
> > can you please try the latest upstream kernel and see if the problem has
> > been fixed or not?
> > we have made quite some EC changes recently and hopefully it can fix the
> > problem for you.
> 
> I'm running 5.7.4-arch1-1 and the issue is still present. Should I try the
> mainline kernel (5.8)?

I was a bit too fast. Charging works now, but the LED doesn't update if you plug or unplug the charger when the laptop is suspended.

I haven't tested if charging works when the charger is plugged in after suspending.

Comment 55 Florian 'rephlex' Panzer 2020-06-29 16:44:57 UTC

Problem still persists with

Linux avis 5.8.0-050800-generic #202006282330 SMP Sun Jun 28 23:35:41 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

on the ASUS ZenBook UX331UN

Comment 56 Carsten Otto 2020-06-30 16:57:24 UTC

(In reply to Zhang Rui from comment #52)
> can you please try the latest upstream kernel and see if the problem has
> been fixed or not?
> we have made quite some EC changes recently and hopefully it can fix the
> problem for you.

I tried 5.8 compiled from source, and didn't see any improvement. The power draw during suspend is still very high, and the LEDs show the same behaviour. Is there anything specific that I'd need to configure? A kernel parameter, /sys/ setting, ...?

Comment 57 Kristian Klausen 2020-06-30 18:24:54 UTC

(In reply to Carsten Otto from comment #56)
> I tried 5.8 compiled from source, and didn't see any improvement. The power
> draw during suspend is still very high, and the LEDs show the same
> behaviour. Is there anything specific that I'd need to configure? A kernel
> parameter, /sys/ setting, ...?

Try running `sudo powertop --auto-tune` as mentioned in this Intel blog post: https://01.org/blogs/qwang59/2018/how-achieve-s0ix-states-linux

There is a lot of power management knobs you can adjust (the Arch wiki list a bunch of them: https://wiki.archlinux.org/index.php/Power_management).

My setup looks like this: (https://gist.github.com/klausenbusk/b0c603381e1ce10dd5db55a239410b03 in case Bugzilla mess up the formatting)
==> /etc/tmpfiles.d/aspm.conf <==
# ASPM is force enabled by the pcie_aspm=force kernel parameter
w /sys/module/pcie_aspm/parameters/policy - - - - powersupersave

==> /etc/tmpfiles.d/energy_performance_preference.conf <==
w /sys/devices/system/cpu/cpufreq/policy?/energy_performance_preference - - - - balance_performance

==> /etc/udev/rules.d/pci_pm.rules <==
SUBSYSTEM=="pci", ATTR{power/control}="auto"

==> /etc/udev/rules.d/scsi_pm.rules <==
SUBSYSTEM=="scsi", ATTR{power/control}="auto"

==> /etc/udev/rules.d/usb_elan.rules <==
# Bus 001 Device 004: ID 04f3:0903 Elan Microelectronics Corp.
SUBSYSTEM=="usb", ATTR{idVendor}=="04f3", ATTR{idProduct}=="0903", ATTR{power/control}="auto"

==> /etc/modprobe.d/audio_powersave.conf <==
options snd_hda_intel power_save=1

==> /etc/modprobe.d/i915.conf <==
options i915 enable_fbc=1 enable_dc=2 enable_guc=3 enable_psr=1

==> /etc/modprobe.d/iwlwifi.conf <==
options iwlwifi power_save=1 power_level=5 d0i3_disable=0 uapsd_disable=0
#options iwlmvm power_scheme=3
#options iwldvm force_cam=0