* API for querying the resume cause
@ 2015-08-20 11:47 Yan Pashkovsky
2015-08-20 21:44 ` Yan Pashkovsky
2015-08-21 2:07 ` Krzysztof Kozlowski
0 siblings, 2 replies; 5+ messages in thread
From: Yan Pashkovsky @ 2015-08-20 11:47 UTC (permalink / raw
To: linux-pm
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: API for querying the resume cause
2015-08-20 11:47 API for querying the resume cause Yan Pashkovsky
@ 2015-08-20 21:44 ` Yan Pashkovsky
2015-08-21 2:07 ` Krzysztof Kozlowski
1 sibling, 0 replies; 5+ messages in thread
From: Yan Pashkovsky @ 2015-08-20 21:44 UTC (permalink / raw
To: linux-pm
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: API for querying the resume cause
2015-08-20 11:47 API for querying the resume cause Yan Pashkovsky
2015-08-20 21:44 ` Yan Pashkovsky
@ 2015-08-21 2:07 ` Krzysztof Kozlowski
2015-08-21 3:17 ` Yu Chen
1 sibling, 1 reply; 5+ messages in thread
From: Krzysztof Kozlowski @ 2015-08-21 2:07 UTC (permalink / raw
To: Yan Pashkovsky; +Cc: linux-pm, Alexandra Yates, Bastien Nocera
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: API for querying the resume cause
2015-08-21 2:07 ` Krzysztof Kozlowski
@ 2015-08-21 3:17 ` Yu Chen
[not found] ` <9D8C9A00-9AA7-4BA1-9953-3DB1A88468D5@gmail.com>
0 siblings, 1 reply; 5+ messages in thread
From: Yu Chen @ 2015-08-21 3:17 UTC (permalink / raw
To: Krzysztof Kozlowski, Yan Pashkovsky
Cc: linux-pm, Alexandra Yates, Bastien Nocera, Aaron Lu, Zhang Rui,
Rafael J. Wysocki
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: API for querying the resume cause
[not found] ` <9D8C9A00-9AA7-4BA1-9953-3DB1A88468D5@gmail.com>
@ 2015-08-21 21:09 ` Yan Pashkovsky
0 siblings, 0 replies; 5+ messages in thread
From: Yan Pashkovsky @ 2015-08-21 21:09 UTC (permalink / raw
To: Yu Chen, Krzysztof Kozlowski
Cc: linux-pm@vger.kernel.org, Alexandra Yates, Bastien Nocera,
Aaron Lu, Zhang Rui, Rafael J. Wysocki
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
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-08-21 21:09 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-08-20 11:47 API for querying the resume cause Yan Pashkovsky
2015-08-20 21:44 ` Yan Pashkovsky
2015-08-21 2:07 ` Krzysztof Kozlowski
2015-08-21 3:17 ` Yu Chen
[not found] ` <9D8C9A00-9AA7-4BA1-9953-3DB1A88468D5@gmail.com>
2015-08-21 21:09 ` Yan Pashkovsky
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.