Power drain on slee, Was: Customize Debian image in a mini desktop
ganesh.krishna at gmail.com
Thu Aug 28 18:35:17 CEST 2008
On Thu, Aug 28, 2008 at 6:10 PM, arne anka <openmoko at ginguppin.de> wrote:
>>> on an off note; I was testing suspend time day before yesterday,
>>> battery 100%, Zhone,xterm,keyboard running(minimum apps I need).
>>> Suspended FR at 3AM. tried to wake it up at 9AM (6hrs). FR battery is
>>> dead. battery reads 3.16V on multimeter. FR refuses to boot/charge the
>>> battery. Had to find a different battery to boot then hot swap the
>>> battery while charging to get back my FR. Lesson learned: Neo likes to
>>> be plugged in when (user is) asleep.
>> Quite strange, my Freerunner stays reliably in sleep (unless someone
>> calls and I don't notice, of course), and consumes only a reasonable
>> amount of power – about what Timo reported in the "29 hours in suspend
>> => 70% battery left" thread.
>> I use the kernel from 2008-08-05 (too lazy to upgrade). What's yours?
uname says 2.6.24, I installed Debian last friday night. have not
> there has to be crucial change in one of the last updates.
> i upgraded tuesday night and seem to see the same problem -- i still use
> the kernel from installation, but the power goes down really quick.
> took it from the charger at about 8:00 and now it is at about 40%, though
> i had it suspending.
There are some (good?) developments to the story. After completely
recharging the battery (100% as shown by the gadget pannel) I put it
to sleep at 2PM, intending to wake it up in 4 hours. The boss calls a
meeting etc etc and I am able look at the FR only at 9PM (7hrs). I
open the FR fully expecting to go thru the hot swap process again BUT,
viola FR wakes up and it still has 48% juice (3.8V open circuit).
These only difference between this experiment and the 6hrs total
drain is that
Experiment 1: 6 hrs total drain
1. FR has been running, sleeping etc for more than 12 hrs.
2. Was plugged in most of the time.
3. the performance of the phone was already extremely sluggish (due to
long up time ?)
4. battery charged to 100%
5. put to sleep
Experiment 2 : 7hrs and 48% left
1. The battery was totally drained.
2. battery charged to 100% thru AC adapter
3. put to sleep _immedietly_ (* this step could be the key)
Before putting to sleep in exp 1, 'top' had showed 'events/0' taking
upto 60% CPU time averaging around 35 -40%, second in line was python
(I have openmoko-panel-plugin running) at 14% and above.
I am just putting these numbers out, I have not idea if/how these will
have any effect at all on the sleep time.
> Openmoko community mailing list
> community at lists.openmoko.org
More information about the community