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

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

On Tue, Nov 26, 2019 at 5:15 PM Kenneth R. Crudup <kenny@panix.com> wrote:
>
>
> On Tue, 26 Nov 2019, Rafael J. Wysocki wrote:
>
> > > BTW, I've got breaking it down to a science now:
>
> > > - Let the battery drain pretty well down (< ~80%)
> > > - Boot the kernel I wish to test, while still on battery
> > > - Intiate a suspend/resume, which will come back OK
> > > - Initiate another suspend
> > > - Plug in the charger. If I have my power meter in, I see it do the PD
> > >   negotiation (it'll start off at 20V/150mA, then it'll PD ramp up to
> > >   a full 2.5-2.75A @20v to charge the battery)
> > > - Try to resume. It'll be totally dead and I have to long-power-button
> > >   to get it back
>
> Huh. So ... I run bleeding edge and grab Linus' tip as it's pushed; I'd
> seen some changes to workqueues in last night's merge. Personally, I feel
> that if workqueues were AFU the kernel would be a hot mess, but at this
> point since there's one in the path of acpi_ec_flush_work() called from
> acpi_s2idle_sync() and I'm kinda desperate at this point for at least
> something to help fix this, I put your 2nd patch back in earnest (uncommented
> out acpi_ec_flush_work() from acpi_s2idle_sync()) and added a pair of
> WARN_ON(1)s (which should dump to pstore- or is that "BUG_ON()"?) around
> the spin_lock/unlock in acpi_ec_query_flushed().

OK, so just to double check if I understand you correctly, you are
running the Linus' tip with this patch on top

https://lore.kernel.org/linux-pm/alpine.DEB.2.21.1911220920500.24730@hp-x360n/T/#m199e175157c9cddf48fdee16681f6c2f0549a364

and with two extra WARN_ON(1) statements in acpi_ec_query_flushed()?