How to get "wake up reason" for Suspend-to-Idle

How to get "wake up reason" for Suspend-to-Idle

[Kai-Heng Feng]

We are seeing laptops wake up when Thunderbolt dock gets plugged, or
even wake up on AC plugging.

On Windows these events are logged with "Wakeup Reason", and if the
wakeup event is from unplugging AC, the system will be put to suspend
again.

So I wonder if it's possible to get the "Wakeup Reason" under Linux?

'/sys/power/wakeup_count' seems to be insufficient for this purpose.

Kai-Heng

Re: How to get "wake up reason" for Suspend-to-Idle

[Mika Westerberg]

Hi,

On Wed, Aug 17, 2022 at 03:08:18PM +0800, Kai-Heng Feng wrote:
> We are seeing laptops wake up when Thunderbolt dock gets plugged, or
> even wake up on AC plugging.
> 
> On Windows these events are logged with "Wakeup Reason", and if the
> wakeup event is from unplugging AC, the system will be put to suspend
> again.
> 
> So I wonder if it's possible to get the "Wakeup Reason" under Linux?
> 
> '/sys/power/wakeup_count' seems to be insufficient for this purpose.

I don't know if there is a way but unfortunately several systems (or
their firmware) are expecting Windows style "dark resume" so they pretty
much wake up each time something gets plugged or even unplugged to these
ports. Linux does not have similar mechanism at the moment but I think
at least if you have lid closed it will eventually go back to s2idle.

Re: How to get "wake up reason" for Suspend-to-Idle

[Kai-Heng Feng]

On Wed, Aug 17, 2022 at 6:30 PM Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
>
> Hi,
>
> On Wed, Aug 17, 2022 at 03:08:18PM +0800, Kai-Heng Feng wrote:
> > We are seeing laptops wake up when Thunderbolt dock gets plugged, or
> > even wake up on AC plugging.
> >
> > On Windows these events are logged with "Wakeup Reason", and if the
> > wakeup event is from unplugging AC, the system will be put to suspend
> > again.
> >
> > So I wonder if it's possible to get the "Wakeup Reason" under Linux?
> >
> > '/sys/power/wakeup_count' seems to be insufficient for this purpose.
>
> I don't know if there is a way but unfortunately several systems (or
> their firmware) are expecting Windows style "dark resume" so they pretty
> much wake up each time something gets plugged or even unplugged to these
> ports. Linux does not have similar mechanism at the moment but I think
> at least if you have lid closed it will eventually go back to s2idle.

ChromeOS also developed their own version of dark resume [1], which
checks  '/sys/power/wakeup_count' to decide if the system should go
back to suspend again.
However, if there's any spurious wakeup event occurs during s2idle
like [2], checking 'wakeup_count' alone will put the system back to
suspend, and the system will stuck in a wakeup/suspend loop.

So I think it's safer to implement the mechanism in the kernel, by
implementing .suspend_again() callback for s2idle just like what S3
does.
However, to make the right decision on suspend or wakeup we need a
concrete "wakeup reason", but I wonder how do we achieve that?

[1] https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/power_manager/docs/dark_resume.md
[2] https://bugzilla.kernel.org/show_bug.cgi?id=216295

Kai-Heng

Re: How to get "wake up reason" for Suspend-to-Idle

[Mika Westerberg]

On Wed, Aug 17, 2022 at 08:53:00PM +0800, Kai-Heng Feng wrote:
> On Wed, Aug 17, 2022 at 6:30 PM Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> >
> > Hi,
> >
> > On Wed, Aug 17, 2022 at 03:08:18PM +0800, Kai-Heng Feng wrote:
> > > We are seeing laptops wake up when Thunderbolt dock gets plugged, or
> > > even wake up on AC plugging.
> > >
> > > On Windows these events are logged with "Wakeup Reason", and if the
> > > wakeup event is from unplugging AC, the system will be put to suspend
> > > again.
> > >
> > > So I wonder if it's possible to get the "Wakeup Reason" under Linux?
> > >
> > > '/sys/power/wakeup_count' seems to be insufficient for this purpose.
> >
> > I don't know if there is a way but unfortunately several systems (or
> > their firmware) are expecting Windows style "dark resume" so they pretty
> > much wake up each time something gets plugged or even unplugged to these
> > ports. Linux does not have similar mechanism at the moment but I think
> > at least if you have lid closed it will eventually go back to s2idle.
> 
> ChromeOS also developed their own version of dark resume [1], which
> checks  '/sys/power/wakeup_count' to decide if the system should go
> back to suspend again.

Right.

> However, if there's any spurious wakeup event occurs during s2idle
> like [2], checking 'wakeup_count' alone will put the system back to
> suspend, and the system will stuck in a wakeup/suspend loop.
> 
> So I think it's safer to implement the mechanism in the kernel, by
> implementing .suspend_again() callback for s2idle just like what S3
> does.
> However, to make the right decision on suspend or wakeup we need a
> concrete "wakeup reason", but I wonder how do we achieve that?
> 
> [1] https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/power_manager/docs/dark_resume.md
> [2] https://bugzilla.kernel.org/show_bug.cgi?id=216295

Do we know why the AER event happens in the first place? I think that's
where we should look first. Perhaps there is something missing int the
Linux AER implementation that causes this?

Re: How to get "wake up reason" for Suspend-to-Idle

[Kai-Heng Feng]

On Wed, Aug 17, 2022 at 9:34 PM Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
>
> On Wed, Aug 17, 2022 at 08:53:00PM +0800, Kai-Heng Feng wrote:
> > On Wed, Aug 17, 2022 at 6:30 PM Mika Westerberg
> > <mika.westerberg@linux.intel.com> wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Aug 17, 2022 at 03:08:18PM +0800, Kai-Heng Feng wrote:
> > > > We are seeing laptops wake up when Thunderbolt dock gets plugged, or
> > > > even wake up on AC plugging.
> > > >
> > > > On Windows these events are logged with "Wakeup Reason", and if the
> > > > wakeup event is from unplugging AC, the system will be put to suspend
> > > > again.
> > > >
> > > > So I wonder if it's possible to get the "Wakeup Reason" under Linux?
> > > >
> > > > '/sys/power/wakeup_count' seems to be insufficient for this purpose.
> > >
> > > I don't know if there is a way but unfortunately several systems (or
> > > their firmware) are expecting Windows style "dark resume" so they pretty
> > > much wake up each time something gets plugged or even unplugged to these
> > > ports. Linux does not have similar mechanism at the moment but I think
> > > at least if you have lid closed it will eventually go back to s2idle.
> >
> > ChromeOS also developed their own version of dark resume [1], which
> > checks  '/sys/power/wakeup_count' to decide if the system should go
> > back to suspend again.
>
> Right.
>
> > However, if there's any spurious wakeup event occurs during s2idle
> > like [2], checking 'wakeup_count' alone will put the system back to
> > suspend, and the system will stuck in a wakeup/suspend loop.
> >
> > So I think it's safer to implement the mechanism in the kernel, by
> > implementing .suspend_again() callback for s2idle just like what S3
> > does.
> > However, to make the right decision on suspend or wakeup we need a
> > concrete "wakeup reason", but I wonder how do we achieve that?
> >
> > [1] https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/power_manager/docs/dark_resume.md
> > [2] https://bugzilla.kernel.org/show_bug.cgi?id=216295
>
> Do we know why the AER event happens in the first place? I think that's
> where we should look first. Perhaps there is something missing int the
> Linux AER implementation that causes this?

The AER happens at Physical Layer as soon as the device hit D3cold, so
I don't know what really happens at such low level.

Here's my proposed solution:
https://lore.kernel.org/linux-pci/20220727013255.269815-1-kai.heng.feng@canonical.com/

Anyway, it's just an example to show why I think it's better to
implement "dark resume" in kernel instead of deferring it to the
userspace.

Kai-Heng