maemo.org Bugzilla – Bug 8004
PR1.1 has introduced a battery drain bug (not wifi related)
Last modified: 2010-03-15 20:52:51 UTC
You need to
before you can comment on or make changes to this bug.
(Settings > General > About product)
EXACT STEPS LEADING TO PROBLEM:
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
I installed PR1.1 via OTA this morning then fully recharged and rebooted 2-3
times. No wifi since rebooting. I do have the browse portrait easter egg
enabled but the browse was not open/running at the time
- using at&t 2G
- no apps running(or in background), only xterminal, phone is pretty much idle
- configured for nokia messaging, 30 mins update
- logged into google/skpye accounts
My settings are:
Connect automatically: at&t internet (non 3G)
Search interval: 10 mins
DO NOT switch to wifi automatically
I've been tracking my battery life over the last 7 days and today I've noticed
a huge battery drain. It went from 78% - 62% free in 1.5 hours. I would usually
only drain 2-3% in 1.5 hours.
My phone is completely stock, no apps installed. I was tracking the battery
from 09:30 - 12:30, everything looked great
at 13:00 I noticed the red exclaimation circle telling me I'm unable to login
to google IM. I left it for 15 mins and then checked battery. drained to 72%.
Noticed the phone warmer than usual
I then disabled both google/skpye IM account. Noted the availability circle
gone, assumed I have logged out. So the drain contined even after I disbaled
all IM accounts.
30 mins later, the battery drops from 72% to 62%. I try to log in to google IM
again.. no luck
- 12:30 I had 78% battery left
- 13:00 I had 72% battery left
- 13:30 I had 62% battery left
I reboot and can immediately login to google IM.
There is no change to my usage pattern or location, I can say for sure that
PR1.1 or the prior minor firmware has caused this battery drain bug. Not sure
if it only happens once IM accounts cannot login or something has caused the IM
account unable to login and needs a reboot.
(always, less than 1/10, 5/10, 9/10)
less than 1/10
EXTRA SOFTWARE INSTALLED:
maemo-geolocation (not active or running since reboot)
Either the bug is:
- what caused the google IM account to unable to login
- why the huge battery drain during this period
Do not have a top output during this time.
I've had the device 2 weeks under the same scenario and location, it only only
today after PR1.1 I've ever seen this issue.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206)
The IM bug happens to me too, but only on MSN. Rebooting does seem to fix it
though. However, I haven't experienced the battery drainage problem.
Does this also happen when you are in Offline mode?
Which exact IM accounts do you have configured?
This only happened once so far (but was after a few intended reboots after
I only have skype + gtalk configured.
I noticed the problem when the red circle with the exclamation! symbol appeared
in the status bar below the connection icon.
gtalk definitely couldn't login and I think I recall the red circle with a
horizonal white car (stop sign) next to the skype account.
As soon as I rebooted, I could log-in and the battery drain went away.
Today, the drain has not occurred, but I fear it could reappear at any time.
The issue of not logging is not such a big issue, but the battery drain is.
Can you check what the code does when login is not possible?
Does it aggressively retry? Could you keep doubling the retry interval 2sec, 4
sec, 8sec, 16sec, 32sec etc etc
What do you mean by "no wifi"? Does it associate to the AP but you are not able
to surf the web nor connect to gmail?
Have you tried turning the browser portrait mode off? My browser wasn't
working, turned it off and everything was fine again :)
It's worth a try, isn't it? ;)
*** This bug has been confirmed by popular vote. ***
no "wifi" means:
I don't turn on wifi, I've set wifi to not connect automatically.
I only use at&t 2G for internet connection. I only used wifi for the OTA
update, disconnected wifi and I rebooted a few times.
I'll try turning off the portrait mode to see that makes any difference. But
again, I've only encountered the huge drain once so far.
Wild guess: Probably if an IM account cannot log in it tries again and again
and of course needs energy for that, so that would not be a bug.
Also, this bug has the potential danger of people commenting on it with
different reasons for this behaviour.
Always make sure to post your exact observations and extra software installed
or this can get messy quite soon which lowers probability to get things fixed.
Needs better steps and more investigation also by those other voters.
(In reply to comment #7)
> Wild guess: Probably if an IM account cannot log in it tries again and again
> and of course needs energy for that, so that would not be a bug.
> Also, this bug has the potential danger of people commenting on it with
> different reasons for this behaviour.
> Always make sure to post your exact observations and extra software installed
> or this can get messy quite soon which lowers probability to get things fixed.
> Needs better steps and more investigation also by those other voters.
> --> moreinfo
If confirmed the battery drain is caused by the retry:
I would consider it a bug if the n900 can drain to flat in 4 hours just because
the IM service providers are down. "Technically" to a developer this might not
be a bug, but in real-life scenario usage it certainly is.
If confirmed the retry is this aggressive, it should be changed to be less so
(e.g keep doubling the retry time, 2,8,8,16,32,64,128 secs)
What "top" shows using CPU? Even 1% usage is relevant if it's constant.
(Better if you run it through SSH instead of XTerm, then XTerm/Desktop/X aren't
(In reply to comment #9)
> What "top" shows using CPU? Even 1% usage is relevant if it's constant.
> (Better if you run it through SSH instead of XTerm, then XTerm/Desktop/X aren't
At the time the drain occurred, I rebooted before I ran "top". Can you guys at
Nokia run an internal test to see if the battery rapidly drains if the IM
accounts cannot login?
FYI: The reason gtalk could not login is still a question mark, but the big
issue is the source of the sudden drain
> Can you guys at Nokia run an internal test to see if the battery rapidly drains > if the IM accounts cannot login?
This was tested on one device connected to WLAN with gtalk and skype not being
able to connect. We didn't see any battery drain.
Can you reproduce this bug and provide "powertop -t 600" output from different
steps where battery drain occurs?
(In reply to comment #11)
> > Can you guys at Nokia run an internal test to see if the battery rapidly drains > if the IM accounts cannot login?
> This was tested on one device connected to WLAN with gtalk and skype not being
> able to connect. We didn't see any battery drain.
> Can you reproduce this bug and provide "powertop -t 600" output from different
> steps where battery drain occurs?
I've not been able to reproduce the issue so far. Some notes:
-Any chance to repeat your test with 3G or Edge? This is how I saw the original
issue. Not sure if this makes a difference internally. I know wifi is much less
hungry than Cellular data
-I got to the state of seeing the 'STOP' (red circle with white bar) sign in
the status menu. Did you get it to that state also, may be a factor?
Where is this powertop command? I dont have it on my device
I had exactly this same issue today and yesterday.
I had a chance to chart my battery drain for today. Here is what happened in
that last 6 hours. I wasn't using 3g for whole day, only edge, no wifi either,
no mediaplayer. Very few browsing (like 3-4 mins) 10-20 mins phone
conversation. And the battery is dead in 6 hours.
I can attach the log of the drain if you are interested along with the load
(from /proc/loadavg) with 10 mins intervals. I even have pretty charts :P
> Where is this powertop command? I dont have it on my device
You need to be root.
> I can attach the log of the drain if you are interested along with the load
> (from /proc/loadavg) with 10 mins intervals. I even have pretty charts :P
Sure. All info that might help is welcome.
Created an attachment (id=2096) [details]
Battery Drain log
This is the log for the battery drain. Fields are:
Time (Unixtime), charge (mA), percentage, 1minload, 5minload, 10minload
Created an attachment (id=2097) [details]
The graphs for the battery.log
Here are some rrdtool charts for the battery.log
I lined the loads and the charge graphics. as you can see, something happens
around 10:50/11:00 am. The load spikes, and everything is downhill from that
I'm also running the same experiment today. This time with 3g enabled (dual
mode). I'll have more comments on the usage after the battery dies today. :)
One more thing: This morning after waking up, the battery was charged
overnight. I shutdown the phone immediately after removing the charger, removed
the battery, let them idle for 30 secs, put the battery back, booted. This time
the battery was 90% full. I plugged it in back to the wall, and it started
charging again. :\
If cosmic rays and boot processes didn't drain my battery 10% in one minute,
something is wrong :)
(In reply to comment #14)
> > Where is this powertop command? I dont have it on my device
> You need to be root.
Which package has 'powertop' command? I don't have it even as root.
> Which package has 'powertop' command? I don't have it even as root.
The "powertop" package, but seems it's not available anymore.
Can you provide a syslog?
To do that, install the klogd and sysklogd debian packages (and probably reboot
the device afterwards). If that is not enough, enable R&D mode
(In reply to comment #20)
> Can you provide a syslog?
> To do that, install the klogd and sysklogd debian packages (and probably reboot
> the device afterwards). If that is not enough, enable R&D mode
I'll try to do that. I need some time, I'm kinda busy :(
What syslog do you need? Only startup log? Or daily usage log? Or all of the
This has been fixed internally already for the upcoming PR1.2 release.
A future public update will include the fix. (This is not always already the
next public update.)
To answer popular followup questions:
* Nokia does not announce release dates of public updates in advance.
* There is currently no access to these internal, non-public build versions.
A Brainstorm proposal to change this exists at
(In reply to comment #22)
> This has been fixed internally already for the upcoming PR1.2 release.
Could you please provide a short description of what was fixed? Personally, I
haven't seen any huge battery drain (other than pulse audio bug) since the
first report. (I'm starting to suspect the drain I initially saw may have been
an extreme case of pulse audio)
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).
Sorry for the bugmail noise (you can filter on this message).