On Mon, Aug 19, 2019 at 5:47 PM Kristian Klausen <kristian@xxxxxxxxxx> wrote:Thanks for the explanation. I don't think I have the expertise to solve the issue, but at least now I'm one step closer.
On 19.08.2019 11.05, Rafael J. Wysocki wrote:Basically, there are two possibilities: either the OS is expected to
On Monday, August 19, 2019 9:59:02 AM CEST Rafael J. Wysocki wrote:Do you have any idea what the issue could be?
On Fri, Aug 16, 2019 at 10:26 PM Kristian Klausen <kristian@xxxxxxxxxx> wrote:
On 02.08.2019 12.33, Rafael J. Wysocki wrote:It is unlikely to help in that case.
Hi All,It was just testing this patch series(461fc1caed55), to see if it would
The v3 is just a rearranged v2 so as to move the post sensitive patch (previous patch 2)On top of the "Simplify the suspend-to-idle control flow" patch seriesThe v2 is because I found a (minor) bug in patch 1, decided to use a module
posted previously:
https://lore.kernel.org/lkml/71085220.z6FKkvYQPX@kreacher/
sanitize the suspend-to-idle flow even further.
First off, decouple EC wakeup from the LPS0 _DSM processing (patch 1).
Next, reorder the code to invoke LPS0 _DSM Functions 5 and 6 in the
specification-compliant order with respect to suspending and resuming
devices (patch 2).
Finally, rearrange lps0_device_attach() (patch 3) and add a command line
switch to prevent the LPS0 _DSM from being used.
parameter instead of a kernel command line option in patch 4. Also, there
are 4 new patches:
Patch 5: Switch the EC over to polling during "noirq" suspend and back
during "noirq" resume.
Patch 6: Eliminate acpi_sleep_no_ec_events().
Patch 7: Consolidate some EC code depending on PM_SLEEP.
Patch 8: Add EC GPE dispatching debug message.
to the end of the series. [After applying the full series the code is the same as before.]
For easier testing, the series (along with some previous patches depended on by it)
is available in the pm-s2idle-testing branch of the linux-pm.git tree at kernel.org:
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=pm-s2idle-testing
fix my charging issue
(https://bugzilla.kernel.org/show_bug.cgi?id=201307), which it didn't.
handle the AC/battery switching events, or the platform firmware
should take care of them. In the former case, the EC should generate
events to be handled by the OS and in the latter one there needs to be
a way to let the platform firmware that it needs to take care of those
events going forward.
In either case there may be a platform-specific action to be carried
out during suspend and resume to set this up as expected which may be
missing.
Reverting the following commits, didn't fix the issue:
OK, thanks for verifying.With 5.3-rc5 the laptops wakes up without any issue when pressing a keyWell, my lid issue seems to be unrelated as it doesn't result from any patches in theI did however notice that my laptop (ASUS Zenbook UX430UNR/i7-8550U)Thanks for your report.
won't wake when opening the lid or pressing a key, the only way to wake
the laptop is pressing the power button.
I also tested mainline (5.3.0-rc4 b7e7c85dc7b0) and 5.2.8 and the laptop
wakes without issue when the lid is opened or a key is presed.
Please refer to the changelogs for details.
I seem to see a similar issue with respect to the lid on one of my
test machines, looking into it right now.
series in question.
First off, please clone 5.3-rc5 from kernel.org and double check if the issue is not
present in that one.
If that's not the case, merge the pm-s2idle-rework branch from my tree on top of it
and retest.
If you still see the issue then, apply the appended patch (on top of the pm-s2idle-reqork
branch ) and, after starting the kernel, do
# echo 1 > /sys/power/pm_debug_messages
suspend the system and try to wake it up through all of the ways that stopped working.
Then, wake it up with the power button, save the output of dmesg and send it to me.
Thanks!
or opening the lid.
With v5.3-rc5+pm-s2idle-testing I can only wake the laptop by pressing
the power button.
So it is unclear to me how the series can cause an issue like that to appear.
dmesg with pm_debug_messages=1 and your patch:This clearly is the power button event causing the system to wake up.
[ 55.646109] PM: suspend entry (s2idle)
[ 55.698559] Filesystems sync: 0.052 seconds
[ 55.698561] PM: Preparing system for sleep (s2idle)
[ 55.700661] Freezing user space processes ... (elapsed 0.210 seconds)
done.
[ 55.911494] OOM killer disabled.
[ 55.911495] Freezing remaining freezable tasks ... (elapsed 0.001
seconds) done.
[ 55.913192] PM: Suspending system (s2idle)
[ 55.913195] printk: Suspending console(s) (use no_console_suspend to
debug)
[ 55.914778] [drm] CT: disabled
[ 55.916057] wlan0: deauthenticating from 64:70:02:a5:fd:02 by local
choice (Reason: 3=DEAUTH_LEAVING)
[ 56.045634] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[ 56.046650] sd 2:0:0:0: [sda] Stopping disk
[ 56.287622] PM: suspend of devices complete after 371.285 msecs
[ 56.287627] PM: start suspend of devices complete after 373.684 msecs
[ 56.307155] PM: late suspend of devices complete after 19.477 msecs
[ 56.312479] ACPI: EC: interrupt blocked
[ 56.352761] PM: noirq suspend of devices complete after 45.205 msecs
[ 56.352770] ACPI: \_PR_.PR00: LPI: Device not power manageable
[ 56.352774] ACPI: \_PR_.PR01: LPI: Device not power manageable
[ 56.352776] ACPI: \_PR_.PR02: LPI: Device not power manageable
[ 56.352779] ACPI: \_PR_.PR03: LPI: Device not power manageable
[ 56.352782] ACPI: \_PR_.PR04: LPI: Device not power manageable
[ 56.352785] ACPI: \_PR_.PR05: LPI: Device not power manageable
[ 56.352788] ACPI: \_PR_.PR06: LPI: Device not power manageable
[ 56.352790] ACPI: \_PR_.PR07: LPI: Device not power manageable
[ 56.352793] ACPI: \_SB_.PCI0.GFX0: LPI: Device not power manageable
[ 56.352800] ACPI: \_SB_.PCI0.RP06.PXSX: LPI: Device not power manageable
[ 56.357057] PM: suspend-to-idle
[ 69.338656] PM: Timekeeping suspended for 12.178 seconds
[ 69.338701] PM: irq_pm_check_wakeup: IRQ 9
[ 69.338704] PM: IRQ wakeup: IRQ 9
The other actions, whatever they were, didn't cause any interrupts to
be triggered.
I suspect that the issue is related to the EC, so please try to revert commit
fcd0a04267ac ACPI: PM: s2idle: Switch EC over to polling during "noirq" suspend
and see if that makes any difference (should revert cleanly).
If that doesn't make any difference, please also try to revert commits
(on top of the above revert)
11f26633cccb PM: suspend: Fix platform_suspend_prepare_noirq()
ac9eafbe930a ACPI: PM: s2idle: Execute LPS0 _DSM functions with
suspended devices
(in this order) and retest.