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.

Comment 2 Andre Klapper 2010-01-15 19:08:59 UTC

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
PR1.1).
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.

Comment 7 Andre Klapper 2010-01-18 15:14:03 UTC

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

(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)

Comment 9 Eero Tamminen 2010-01-18 18:03:50 UTC

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
busy.)

(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
> busy.)
> 

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

Comment 11 Markus Silvan 2010-01-21 10:30:22 UTC

> 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

Comment 14 Markus Silvan 2010-01-22 10:27:28 UTC

> 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
point.

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.

Comment 19 Markus Silvan 2010-01-25 14:31:10 UTC

> Which package has 'powertop' command? I don't have it even as root.
> 

The "powertop" package, but seems it's not available anymore.

Comment 20 Markus Silvan 2010-01-26 10:39:48 UTC

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
(http://wiki.maemo.org/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
> (http://wiki.maemo.org/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
above? :)

Comment 22 Andre Klapper 2010-02-16 12:41:10 UTC

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
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/

(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)

Comment 24 Andre Klapper 2010-03-15 20:52:39 UTC

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).

Comment 25 Andre Klapper 2010-03-15 20:52:51 UTC

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).