Bug 387598

Summary: prevent s2ram-power outage
Product: [openSUSE] openSUSE 11.1 Reporter: Elmar Stellnberger <estellnb>
Component: Mobile DevicesAssignee: E-mail List <mobile-bugs>
Status: VERIFIED WONTFIX QA Contact: E-mail List <qa-bugs>
Severity: Enhancement    
Priority: P4 - Low    
Version: Factory   
Target Milestone: ---   
Hardware: i686   
OS: openSUSE 10.2   
Whiteboard:
Found By: Community of Practice Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Elmar Stellnberger 2008-05-07 08:58:32 UTC
If the user issues an s2ram but little battery charge is left it should suggest suspend to both (i.e s2disk&ram). The time span, the machine is required to outlast asleep, may be configurable f.e. to 6 hours; it will be much higher than the remainingly available worktime.

  As far as the hardware allows that to be realized, there should also be a mechanism to prevent resume from s2ram if insufficient battery charge is left to power the machine on again. It can happen easily that the machine still has enough power to keep the machine in s2ram, though not enough to power it on again, so that the session is left by an inappropriate resume rather than a real power outage by a longlasting sleep.
  By the usage of W. the user can run to obtain some power, if he realises that resume from s2ram is refused because of insufficient battery charge.
Comment 1 Forgotten User ZhJd0F0L3x 2008-05-09 10:25:04 UTC
Unfortunately, there is no way to decide know how long a machine will last in s2ram (my machine lasts > 12h if i suspend it with the battery at 1%)

Generally, a mechanism to let the user configure "use s2both instead of s2ram if below XX % of battery" seems like a good idea, and i will discuss this with the power-applet developers once we have the infrastructure to do s2both in place.
Comment 2 Elmar Stellnberger 2008-09-20 14:31:46 UTC
  Why not log the power consumption for the latest standby periods to determine the expected and worst case battery duration before entering standby mode? 
This will even be more reliable than querying the expected battery consumption from a hardware database could ever be, since any battery is going to wear down by time (an old accu may just last half the time of a new one).
Comment 3 Elmar Stellnberger 2008-09-20 14:35:59 UTC
Why not offer s2both to the user via kpowersave as well? That will be expedient if the user knows that the machine should stay suspended for a longer time period or just for reasons of safety (user accidentially removes accu).
Comment 4 Danny Al-Gaaf 2008-09-22 18:25:16 UTC
We can implement it as soon as pm-utils and HAL fully supports s2both. 

@Seife: what's the current status of s2both in pm-utils for 11.1/CODE11 ?
Comment 5 Forgotten User ZhJd0F0L3x 2008-09-23 09:47:14 UTC
still work in progress.
Comment 6 Elmar Stellnberger 2009-06-21 16:34:44 UTC
What about s2both now? Is there still any endeavor to finish what has begun so promising in May 2008?

> s2both
s2both: Could not stat the resume device file. Reason: No such file or directory
Comment 7 Holger Macht 2009-06-24 13:07:36 UTC
s2both --help
[...]
-r, --resume_device <resume_device>	device that contains swap area
[...]

This worked the last time I tried.
Comment 8 Elmar Stellnberger 2009-06-24 13:16:13 UTC
  At me it simply did an s2disk not entering s2ram-mode.
Besides this I wonder if there should not be any powersaved integration.
Comment 10 Uwe Drechsel 2011-08-26 10:54:22 UTC
The lifecycle of openSUSE 11.2 ended on May 12th 2011.

I'm closing this bug to make it easier to focus on upcoming releases.

Thank you for reporting this issue and we are sorry that 
we have not be able to fix it before this version reached 
its end of life.  If you would still like to see this bug fixed
and are able to reproduce it against a maintained  version, 
please reopen this bug and change the 'version' of this bug 
to the applicable version.
Comment 11 Uwe Drechsel 2011-08-26 10:58:13 UTC
The lifecycle of openSUSE 11.2 ended on May 12th 2011.

I'm closing this bug to make it easier to focus on upcoming releases.

Thank you for reporting this issue and we are sorry that 
we have not be able to fix it before this version reached 
its end of life.  If you would still like to see this bug fixed
and are able to reproduce it against a maintained  version, 
please reopen this bug and change the 'version' of this bug 
to the applicable version.