ds-backup uses "sleep()", won't wake out of idle suspend.

[cjb]

We should make ds-backup set a wakeup alarm for the time it chooses to perform the backup, else it won't happen in the presence of idle suspend.

[martin.langhoff]

Happy to do so. Any hints on how to do that?

ISTR asking about sleep() @1CC, but didn't get much clarity as what the appropriate code would be...

[cjb]

Ah, I was thinking in the 9.1 timeframe -- the main reason I'm writing this is to add it to a tracker bug of things to fix before turning on idle suspend by default.

The generic code for setting a wakeup alarm is of the form "rtcwake +20m". I think we're going to wrap this in a python library for setting and managing alarms. Is ds-backup able to use Python libraries okay?

Sorry for filing this without mentioning when/how it should be done; wanted to make sure I didn't lose track of it. :)

[martin.langhoff]

Ah, I didn't understand initially.

Python is good - ds-backup can use it - but it decides to sleep while in bash (therefore having a lot smaller mem footprint.

If there is a tiny C proggie around that can be called from shell cheaply as well as the python libs, then we can keep a bit more memory for end users and whatever it is that they do with their laptops :-)

[pgf]

the "rtcwake" that cjb refers to is a standalone program, so i think it's what you're looking for.

[gregorio]

Hi Guys,

Just came across this one in a clean up of the roadmap. It looks important. Should we track it in the power work?

http://wiki.laptop.org/go/Feature_roadmap/Improved_battery_life

Definitely do not want backups to fail in an ugly way due to sleep modes coming on.

Thanks,

Greg S

[martin.langhoff]

This issue needs revisiting for the F11 builds. CJB - what's the situation w the idle wake for our F11 builds?

[Quozl]

testing using the following shell command:

time rtcwake --mode mem --utc --seconds 90

results by model and build:

test unit	model	build	result
QUOZL E C2	XO-1	F9 802	slept for 92 seconds then woke
QUOZL A C2	XO-1	F11 os8	slept for 92 seconds then woke
QUOZL G B2	XO-1.5	F11 os33	slept for 93 seconds then woke
QUOZL F B2	XO-1.5	F11 os33	slept for 91 seconds then woke

rtcwake currently looks functional.

[Quozl]

Replying to Quozl:

Same result on os34.

[martin.langhoff]

Once suspend/resume kinks are ironed out, what I will test here is that the /bin/sleep -> libc -> kernel internals stack does the right thing and (a) allows the machine to suspend and (b) sets an appropriate rtc wakeup.

So test plan:

1. set all "aggressive suspend" options to On
2. run a test shell script from Terminal.xo and VT

   #!/bin/bash -x 
   echo Starttime `date -u ` >> /tmp/testsleep
   sleep 180
   echo `date -u `
   sleep 180
   echo Endtime `date -u `
   

Then start the script, leave machine idle (free to suspend - verify dmesg output) and return after 7 minutes.

[dsd]

I don't think we're expecting sleep to set a wakeup point.

And we also think that only one rtcwake point can be installed at any one time. So even if you set one to coincide with that wakeup, someone else might set another one afterwards.

I guess we have work to do here.

[triagebot]

changed by irc user Quozl:

[cjb]

We aren't going to get this done for 1.5-final, so we need a workaround. (What does olpc-update-query do? Probably want to do that.)