API for querying the resume cause

API for querying the resume cause

[Yan Pashkovsky]

Dear developers,

My name is Yan and I was redirected here from kernel bugzilla
(bugzilla.kernel.org/show_bug.cgi?id=102991). I would like to discuss
API for supporting delayed hibernation.

Original post:

     Please add API for querying the resume cause
     The purpose of this API - is support of delayed hibernation (feature
     that works for a long time in Windows). A laptop first Suspend to
     RAM, then after a time save state to disk and power off completely.
     But system must know the reason of waking up (was it user or turning
     into hibernation). RTC wakeup event isn't reliable.
     SystemD needs such API, see more at
     github.com/systemd/systemd/issues/926


I was discussing it earlier with Lennart Poettering, he said he can't
rely on rtc timer, he needs some API.
Lennart(github.com/systemd/systemd/issues/926):

     On Linux we have no API for querying the resume cause. Patching
     around this sounds like a gigantic hack... Especially as RTC-based
     wakeups are not really reliable on many systems... On such systems
     where the RTC wakeup is missed and the user resumes the machine
     manually later on the system will immediately go to hiberantion,
     which is clearly not a good idea.

     Sorry, but I am really not convinced this could be any more than a
     gigantic hack.

     Please before looking into something like this, let's at least get a
     proper API into the kernel that reports the precise wakeup reason to
     userspace. If we have that, then we can consider hooking this up
     from userspace. Will close this for now, as I don't think we should
     hack something up like this without proper kernel support for such a
     logic.


PS I use mailing list system for the first time. Am I to subscribe to it
somewhere? Will feedback be delivered to my email address after sending
this email, without any actions?

King regards,
Yan

Re: API for querying the resume cause

[Yan Pashkovsky]

Hi, I have subscribed to linux-pm@lists.linux-foundation.org and 
Majordomo@vger.kernel.org (linux-pm). I've written you earlier, hope you 
received my message. I haven't received any replies, so I send this 
message again, cause I think my message was declined.

20.08.2015 14:47, Yan wrote you:
 > Dear developers,
 >
 > My name is Yan and I was redirected here from kernel bugzilla
 > (bugzilla.kernel.org/show_bug.cgi?id=102991). I would like to discuss
 > API for supporting delayed hibernation.
 >
 > Original post:
 >
 >     Please add API for querying the resume cause
 >     The purpose of this API - is support of delayed hibernation (feature
 >     that works for a long time in Windows). A laptop first Suspend to
 >     RAM, then after a time save state to disk and power off completely.
 >     But system must know the reason of waking up (was it user or turning
 >     into hibernation). RTC wakeup event isn't reliable.
 >     SystemD needs such API, see more at
 >     github.com/systemd/systemd/issues/926
 >
 >
 > I was discussing it earlier with Lennart Poettering, he said he can't
 > rely on rtc timer, he needs some API.
 > Lennart(github.com/systemd/systemd/issues/926):
 >
 >     On Linux we have no API for querying the resume cause. Patching
 >     around this sounds like a gigantic hack... Especially as RTC-based
 >     wakeups are not really reliable on many systems... On such systems
 >     where the RTC wakeup is missed and the user resumes the machine
 >     manually later on the system will immediately go to hiberantion,
 >     which is clearly not a good idea.
 >
 >     Sorry, but I am really not convinced this could be any more than a
 >     gigantic hack.
 >
 >     Please before looking into something like this, let's at least get a
 >     proper API into the kernel that reports the precise wakeup reason to
 >     userspace. If we have that, then we can consider hooking this up
 >     from userspace. Will close this for now, as I don't think we should
 >     hack something up like this without proper kernel support for such a
 >     logic.
 >
 >
 > PS I use mailing list system for the first time. Am I to subscribe to it
 > somewhere? Will feedback be delivered to my email address after sending
 > this email, without any actions?
 >
 > King regards,
 > Yan

Re: API for querying the resume cause

[Krzysztof Kozlowski]

2015-08-20 20:47 GMT+09:00 Yan Pashkovsky <yanpaso@gmail.com>:
> Dear developers,
>
> My name is Yan and I was redirected here from kernel bugzilla
> (bugzilla.kernel.org/show_bug.cgi?id=102991). I would like to discuss
> API for supporting delayed hibernation.
>
> Original post:
>
>     Please add API for querying the resume cause
>     The purpose of this API - is support of delayed hibernation (feature
>     that works for a long time in Windows). A laptop first Suspend to
>     RAM, then after a time save state to disk and power off completely.
>     But system must know the reason of waking up (was it user or turning
>     into hibernation). RTC wakeup event isn't reliable.
>     SystemD needs such API, see more at
>     github.com/systemd/systemd/issues/926
>
>
> I was discussing it earlier with Lennart Poettering, he said he can't
> rely on rtc timer, he needs some API.
> Lennart(github.com/systemd/systemd/issues/926):
>
>     On Linux we have no API for querying the resume cause. Patching
>     around this sounds like a gigantic hack... Especially as RTC-based
>     wakeups are not really reliable on many systems... On such systems
>     where the RTC wakeup is missed and the user resumes the machine
>     manually later on the system will immediately go to hiberantion,
>     which is clearly not a good idea.
>
>     Sorry, but I am really not convinced this could be any more than a
>     gigantic hack.
>
>     Please before looking into something like this, let's at least get a
>     proper API into the kernel that reports the precise wakeup reason to
>     userspace. If we have that, then we can consider hooking this up
>     from userspace. Will close this for now, as I don't think we should
>     hack something up like this without proper kernel support for such a
>     logic.

A little bit similar work from Alexandra Yates (CC-ed):
Report interrupt(s) that caused system wakeup
http://comments.gmane.org/gmane.linux.power-management.general/63805

The need of such API was also mentioned some time ago by Bastien Nocera (CC-ed):
https://wiki.gnome.org/BastienNocera/KernelWishlist

It seems like a good topic for Kernel Summit... but it's too late I think.

>
> PS I use mailing list system for the first time. Am I to subscribe to it
> somewhere? Will feedback be delivered to my email address after sending
> this email, without any actions?

You sent it correctly. Mail reached the list.

Best regards,
Krzysztof

Re: API for querying the resume cause

[Yu Chen]

On 08/21/2015 10:07 AM, Krzysztof Kozlowski wrote:
> 2015-08-20 20:47 GMT+09:00 Yan Pashkovsky <yanpaso@gmail.com>:
>
> A little bit similar work from Alexandra Yates (CC-ed):
> Report interrupt(s) that caused system wakeup
> http://comments.gmane.org/gmane.linux.power-management.general/63805
>
This topic is interesting : )
BTW, in github.com/systemd/systemd/issues/926, Lennart is worried
about rtcwake unstable platforms. How about using suspend-to-idle
on these platforms, and leverage a timer instead of rtcwake..

Best Regards,
Yu
>
>
> Best regards,
> Krzysztof

Re: API for querying the resume cause

[Yan Pashkovsky]

I see that the community is awared of such problem. I would like to ask 
how to track  status of this API implementation except of receiving tons 
of emails in this mailing list?  :) My bug report was closed.  I would 
like to contact Lennart when it would be ready.

21.08.2015 06:17, Yu Chen пишет:
 > On 08/21/2015 10:07 AM, Krzysztof Kozlowski wrote:
 >> 2015-08-20 20:47 GMT+09:00 Yan Pashkovsky <yanpaso@gmail.com>:
 >>
 >> A little bit similar work from Alexandra Yates (CC-ed):
 >> Report interrupt(s) that caused system wakeup
 >> http://comments.gmane.org/gmane.linux.power-management.general/63805
 >>
 > This topic is interesting : )
 > BTW, in github.com/systemd/systemd/issues/926, Lennart is worried
 > about rtcwake unstable platforms. How about using suspend-to-idle
 > on these platforms, and leverage a timer instead of rtcwake..
 >
 > Best Regards,
 > Yu
 >>
 >>
 >> Best regards,
 >> Krzysztof
 >
 >