Re: Help me fix a regression caused by 56b9918490 (PM: sleep: Simplify suspend-to-idle control flow)

["Rafael J. Wysocki" <rafael@kernel.org>]

On Sat, Nov 23, 2019 at 11:24 AM Kenneth R. Crudup <kenny@panix.com> wrote:
>
>
> On Fri, 22 Nov 2019, Rafael J. Wysocki wrote:
>
> > BTW, is the ec_no_wakeup=1 workaround still effective?
>
> OK, I was wrong the first time, at least from the new Linus' tip (as of
> merge commit 2027cabe6af anyway). So I did some testing, and I now have a matrix:
>
> If "sleep_no_lps0" == 1, the machine never goes fully to sleep; the power
> light stays on and the backlight goes off, but if I have external monitors
> connected they're still showing dmesg activity. This is independent of the
> state of "ec_no_wakeup".

Hmm.  The external monitors part is something you have never mentioned.

> If "ec_no_wakeup" == 1, the system *at times* will go to sleep and never return

This is unclear.

What exactly do you mean by "go to sleep"?

Which part of the behavior does the "at times" phrase apply to?  The
"going to sleep" or coming back?  Or both?

> (i.e. no power light comes on, it's totally unresponsive until I do a hard
> reset with a power-button long-press) whether I'm plugged in or not.
> This is new behavior.

So how did it behave in 5.3.y?

> If "ec_no_wakeup" == 0, the system goes fully to sleep and either of the
> power button, lid opening or hitting a key resumes the laptop, but if I'm
> plugged in and actually charging when I suspend (and I suspect if I plug
> it in during suspend) it never returns, as in the case above.

OK, so ec_no_wakeup doesn't really change the behavior substantially,
it only makes certain things more or less likely to happen.

Does it still hang if you use the keyboard to wake up the system?

> Help! What can I do to return to the behavior of right before the s0 rework?

I guess you mean the 5.3.y behavior.  And what was it?

> Where in the code could I start looking to try to find out where the machine
> goes dead?

Well, because you identified 56b991849 as the first bad commit, the
following three lines of code in drivers/acpi/sleep.c are likely to be
the source of the problem:

        acpi_os_wait_events_complete(); /* synchronize EC GPE processing */
        acpi_ec_flush_work();
        acpi_os_wait_events_complete(); /* synchronize Notify handling */

Can you please try to comment them out and retest?

Note that you most likely won't be able to wake up the system via the
lid/power button without them, so use the keyboard to way it up during
that test.

Thanks!