I have this same problem, but a bit more of use. I use skype&gtalk, as well
email check once in 30 minutes. Battery lasts about 6-8 hours. I'm hoping that
it will get better after couple more charges, but still I see that after device
starts to get older, we are heading for big problems.

So, my problem is not as severe as David's problem, but still battery life is
way smaller from promises to be able to do "full day of online use".

*** This bug has been confirmed by popular vote. ***

I noticed that having account plugins such as haze enabled will drain your
battery.

I had MSN+Yahoo+Skype+Gtalk+SIP signed in, lasted only 8 hours on medium usage.

Once I disabled everything and left SIP only, it can last a good 20 hours on
medium usage.

It is a battery drain problem somewhat related to wifi connection.
Here it is my reproducibility schema:

1.Start a wifi connection (no matter of what parameters are in use, if 10/100
mW or WPA) or simply search for a wlan and then turn off it (i.e. disconnect).

2. You will start to experienxce a massive battery drain and the device getting
warmer (since I think the wifi chip stays ON or maybe the cpu doesn't reach S4
state anymore).

3. To stop the "fast discharge" mode you have to reboot. If then you reconnect
to wifi the problem starts again.

Maybe other users have a different experience with this bug, but it is always
related to wifi.

I've experienced the exactly same problem that makes this phone useless and
explains why so short after launch you can get a lot of used nokia n900 on
ebay.
People wants to get rid of them.
The setup to reproduce the problem is as reported:
GPS: OFF
BLUETOOTH: OFF
WIFI: ALWAYS ASK
SCAN INTERVAL: NEVER

Nonetheless after some very moderate use with a few minutes wifi the phone gets
warm (even if wifi is turned oof at this point) and battery starts draining in
minutes. It does not happen if you only use 3g networking.

This must be connected with the somewhat incoherent setup GUI for wifi-3g
networking which behaves in unexpected ways (at least from my viewpoint):
1) set network settings to:
   Automatic connection: always ask
   Scan interval: never
2) Go to desktop applet menu and click: internet connection
   3g and wifi networks are discovered, so wifi scanning seems not to
   be turned off at all.
I wonder if it is possible to turn off wifi the same way it is done in the 
HTC Dream by unloading the kernel modules. Would try this myself but i still
have to find out exactly which modules are responsible for wifi.

Hope this problem will get fixed soon or i'll sell my N900 on ebay to before
price goes down to much.

Would be interesting to see if the same bug happens using the ti
sta_dk_4_0_4_32
driver bundled with the android source, as i never experienced this issue on
phones with the same 1251 chip like the G1.

(In reply to comment #4)
> It is a battery drain problem somewhat related to wifi connection.
> Here it is my reproducibility schema:

I am unable to reproduce this - top and powertop show nothing out of the
ordinary after connecting and disconnecting WLAN.

I have experienced a fast battery drain situation, but unfortunately I didn't
check what was causing it that time. I'll try to do that if it happens again.

I've tried to find some logic on this issue for a while, and I cannot find any.
This problem seems to be random, but sometimes if I leave calendar software on
(I have ~60-70 classes set there), it raises CPU usage to ~70% (measured using
top on terminal). After restarting calendar, sometimes this issue stays, but if
you restart device, it goes away. Most of the time, calendar doesn't consume
cpu so heavily.

But this is not only way to explain this, since also messaging software does
same thing. Funny part of this is that it doesn't matter if you are online or
not, but if you just have your messaging (sms, IM or email) open, sometimes it
starts to eat CPU & consume power.

Only clue what I have found on this issue is that there is some bug with 3G
and/or WLAN, which causes some software to go crazy. I haven't installed any
devel software and I don't run any other than basic software which are already
included.

So, this is just a pure guess on this issue, but it seems that switching
between wlan & 3G is the problem here, but I have not still found a way to
reproduce this problem every time. 

Some networking details if they help:
WLAN used at home is always full bars, 3G network is rarely fluctuating,
usually says 3G or 3.5G. Sometimes when I'm inside my university, device drops
all connections and stays 2G, after restarting, 3G comes back alive, even if I
stay at same place. During that time. when phone has dropped 3G, I cannot make
any phone calls, it just gives "general error".  This might also be some
indicator for problems on managing connections.

>So, this is just a pure guess on this issue, but it seems that switching
>between wlan & 3G is the problem here, but I have not still found a way to
>reproduce this problem every time. 

I recall that one time when my phone was getting hot and drained battery
i removed manually the wl12xx module and then i was not able to establish
a new 3g connection and had to reboot.

Created an attachment (id=1698) [details]
dmesg.txt

dmesg of a case this noon when the phone started to get hot again after a short
wifi session. Anything looks suspicious as far as i can tell, unless the last
snippet:

[81891.834930] wl1251: firmware booted (Rev 6.0.4.156)

Why needs the firmware to be booted again after i shut down the connection?

Created an attachment (id=1715) [details]
dmesg.txt

dmesg after battery heavy drain

Created an attachment (id=1716) [details]
powertop after battery heavy drain

powertop after battery heavy drain

Created an attachment (id=1717) [details]
top after battery heavy drain

top after battery heavy drain

Created an attachment (id=1718) [details]
/proc/interrupts after battery heavy drain

/proc/interrupts after battery heavy drain

The above attached files where created after a classic case of battery drain:
1) phone was hooked all night to the charger
2) 8,00 - 8,15 wifi activity to check for software updates
3) bluetooth, gps, wifi and packet data turned off
4) phone was all time in my pocket, no activity at all.
5) at 11,00 phone was warm and battery at about 50%
6) as soon as i reached my office i copied dmesg, top and powertop output and 
   catted /proc/interrupts.

Let me know for the next time if I can provide other/better informations.

I have done quite a lot of testing and in my case it is caused by Wi-Fi.
Connecting to my home Wi-Fi and immediately disconnecting will already trigger
it. Simple searching for available Wi-Fi connections doesn't trigger it.

Summary of my tests:
Idle without Wi-Fi bug triggered: 9.1 days (calculated from 9.3 hour test).
Same as above with 3G internet connection idle as well: 3.1 days (calculated
from 1.9 hour test).
Idle after triggering Wi-Fi bug: 6.9 hours! (Calculated from 1.0 hour test).

See full information at:
http://talk.maemo.org/showthread.php?p=416799#post416799

My router is a Linksys Wag160N:

--- System Information ---
Vendor: Linksys
ModelName: WAG160N
Firmware Version: A1.00.14 , 2009-04-02T13:48:39
GUI Version: A1.00.14_007
Boot Version: 1.0.37-5.4
Hardware Version: 0.01

--- DSL Information ---
DSL Driver Version:  AnnexA version - A2pB022g.d20e
DSL VPI/VCI:         8/35
DSL Status:          ShowtimeRetrain Reason:    0
DSL Mode:            G.DMT
DSL Channel:         INTR
DSL Upstream Rate:   480 Kbps
DSL Downstream Rate: 7616 Kbps

                      Down         up    
DSL Noise Margin:    14.1 dB      29.0 dB
DSL Attenuation:      9.0 dB       2.0 dB
DSL Transmit Power:  11.8 dBm      9.9 dBm

--- Wireless Information ---
Wireless Driver Version: 6.1.1.111
Wireless Tools Version: 28
Wireless Status: Enabled
Wireless Wide Channel: 4
Wireless Standard Channel: 2- 2.417GHZ
Wireless SSID: xxx
---

Security Mode:   WPA2-personal    

Encryption:      TKIP/AES
Pre-Shared Key:  xxxxxxx    
Key Renewal:      3600 seconds

The router I use with the Wi-Fi battery drainage bug (haven't tried any other
Wi-Fi's):

D-Link DGL-4300 Wireless 108G Gaming Router

Wi-Fi settings:
Channel 1
Mixed 802.11g and 802.11B
Invisible mode
WPA-personal
WPA2 prefered
TKIP & AES
3600 sec
Disabled 108G boost thingie on the router.

I have the same problem / frustration.

I have the account-plugin-haze installed.
The phone is fully charged at 9 am, and after some chat and surf, the battery
dies at 3 pm.

I don't know if it's related to a wifi connection. I'll make the test and give
a feedback.

I have the same problem with msn (haze) plugin but i am only connected thru 3G,
i never use wifi or search for it. When i stay signed on to msn or any other im
network the battery dies in short time with very moderate use.

fix this asap. big issue. wondering why it wasnt picked up earlier???

One more example:
1) reboot phone
2) 10 min wifi connection
3) turn off wifi, turn off 3g, set wifi power 10mw, wifi turned off
   bluetooth off, gps off, no widgets, standard software + openssh
4) phone on charger all night
5) at morning detach from charger
6) after 30 min phone starts feeling warm, no sign of battery drain in the
indicator yet (maybe to early for its sensibility), no activity was done.
6) phone gets cold only after a reboot

Comment 23 Andre Klapper 2009-12-10 16:22:28 UTC

(In reply to comment #21)
> fix this asap. big issue. wondering why it wasnt picked up earlier???

Please do not post unhelpful non-technical comments. This is not a forum.

I'm getting this with Dynamode R-ADSL-CW4-EG

Sometimes my N900 fails to find the wireless signal and needs to be rebooted. I
don't know whether this is related. (It's definitely an N900 problem - my N82
has no trouble with it.)

Incidentally, my network uses a hidden SSID. Is this common with other victims
of this bug?

I tested that hidden SSID is not the issue. I changed configuration to visible
from Wi-Fi router and for the Wi-Fi connection settings. Then rebooted the
phone, connected to Wi-Fi and disconnected Wi-Fi. During an hour test, the
battery draining was just like before, almost 200 mAh in an hour test on total
idle when it should use less than 10 mAh based on tests without triggering
Wi-Fi bug.

My SSID is not hidden.

I believe this happened to me today. I noticed the device was warm after being
in standby and the battery level had dropped massively. I would love some
information from Nokia/Maemo as to whether this is a hardware/software problem,
if there is workaround and/or if there is an expected fix date.

I'm pretty sure I'm having this issue also with a Buffalo WHR-G54S running
DD-WRT v24-sp1. The exception to the original bug report is that I get a
battery life around 10 hours (this of course debends heavily on the usage and
settings) and the N900 doesn't get too warm to notice it.

Today I rebooted the N900 and haven't used WLAN and after 12 hours of use I
still have over half of the battery left.

My settings on WLAN are:

Network: Mixed
SSID: (hidden)
Channel: 6 (auto)
Encryption: WPA2 Personal Mixed

The combining factor seems to be the used encryption.

(In reply to comment #28)
> The combining factor seems to be the used encryption.

This may be coincidental. Wireless networks are normally encrypted.

Of course, if you want to expose your network for experimental purposes, you
are free to do so :-)

(In reply to comment #28)
> My settings on WLAN are:
> 
> Network: Mixed
> SSID: (hidden)
> Channel: 6 (auto)
> Encryption: WPA2 Personal Mixed
> 
> The combining factor seems to be the used encryption.
> 

The most notable common factor seems almost all reports were mentioning hidden
SSID at some point, which is higly unlikely to find, regarding almost nobody
usually hides his SSID (as it's *not* giving any increased security).
Nota bene: if device has any WLAN connection configured that's set to 'hidden',
then the device needs to *send* a request to every WLAN AP found with hidden
SSID to query if it's the one (with the hidden SSID) configured on device's
WLAN setup

jOERG

(In reply to comment #30)
> The most notable common factor seems almost all reports were mentioning hidden
> SSID at some point, which is higly unlikely to find, regarding almost nobody
> usually hides his SSID (as it's *not* giving any increased security).
> Nota bene: if device has any WLAN connection configured that's set to 'hidden',
> then the device needs to *send* a request to every WLAN AP found with hidden
> SSID to query if it's the one (with the hidden SSID) configured on device's
> WLAN setup

I tested my Wi-Fi with hidden SSID taken off. Same battery draining bug
occurred with visible SSID.

(In reply to comment #31)
> I tested my Wi-Fi with hidden SSID taken off. Same battery draining bug
> occurred with visible SSID.
> 

You need to delete all wlan connections from "settings internet" that have
"hidden" set. It's not sufficient to change the actually used connection's
setup

My SSID is not hidden nor do I have any other routers with hidden SSID
in network configs. The battery drain happened always after having turned
a short wifi connection off. It does not happen with 3g connections.
The common factor seems to be WPA2-personal encryption or there is something
faulty in the wlan driver's power management (maybe when used with N capable
routers?). Would be interesting to see if the same problem happens with the
Texas Instruments written drivers at
http://android.git.kernel.org/?p=platform/system/wlan/ti.git;a=summary as I
never experienced the same issues on my G1.
Are toolchain, kernel config and kernel source for the N900 availbale?

ok, I never seen that issue.
Got 2 AP setups - WEP and WPA2, both non N capable - which are used frequently

(In reply to comment #32)
> You need to delete all wlan connections from "settings internet" that have
> "hidden" set. It's not sufficient to change the actually used connection's
> setup

Yes, I did all that. And rebooted phone after changing all settings. Still
happened.

As for other posts.. My big brother has WPA2 in use on n-capable Wi-Fi router
without problems.

And just searching for Wi-Fi connections (it does that automatically when
manually starting internet connection) does NOT trigger the bug. Even with it
finding the hidden SSID one.

Comment 36 Neil MacLeod 2009-12-14 21:30:40 UTC

My fully charged N900 left my home network (Linksys WRT-610N, 11g, WPA2,
visible SSID) at 9am and had a flat battery by 3pm the same day having been on
T-Mobile UK 3G during that period. No hidden SSID configured (ever).

On the plus side, my N900 is solid as a rock so can't complain too much. ;-)

I've gathered some more info about this battery drain issue.
The bug is due to multiple factors:

1) wlan modules are loaded at boot
2) there is no way to unload them for the user on the GUI unless he gains root
and knows what to do
3) even if the user sets connection to always ask in connection manager the
modules stay in memory
4) at this point the user expects that wifi is turned off (same thing applies
for BT)
   and in fact in the bug reports we always read: WIFI OFF
5) in reality the modules are still loaded in memory and the wifi card is
initialized
   and sucking power.

If in this scenario we are bitten by a bug in the wifi card driver that is
triggered in connection
with some particular (faulty?) routers we can still shut down the network
connection
but the wlan card will remain in a (undefined?) state continuing to consume
power abnormally
and draining the battery in a couple of hours.
A simple empirical demonstration of my suspects was achieved by connecting to
my router
in the same conditions that systematically triggered the drain bug
and by unloading all wifi kernel modules (wl12xx, crc7, mac80211) after
disconnection.
After 10 hrs I'm still at 90% battery.
One more hint that could prove my theory is that the folks at htc that use the
same
wifi chip in their G1 provide a GUI setting to turn on/off wifi that
effectively
loads and unloads the wlan kernel module.
A simple fix on the short term for people hit by this bug is would be:
1) install the gainroot package
2) create a script to load unload the wifi modules when needed.
-------------------------------------------------------
#!/bin/sh
if [ `lsmod | grep -c wl12xx` -gt 0 ] ; then
        #echo -n "Shutting down  wlan0 interface..."
        #ifconfig wlan0 down
        #echo "done"
        echo -n "Unloading wlan modules..."
        rmmod wl12xx
        rmmod mac80211
        rmmod crc7
        echo "done"
else
        echo "Loading wlan modules..."
        modprobe wl12xx
        echo "done"
fi
---------------------------------------------------------

I've tested it but sadly it doesn't work as it is
indeed capable to load/unload the modules but
after reloading them it is not possible to 
establish a connection. There must be some 
initialization stuff missing I have not found yet.
In the long term an option should be added to the
GUI to allow the user to shut down wifi (and BT) if not needed.
Hints are appreciated....

Wondering if that's the case to change bug's title in something more specific,
since the discussion is focalizing on WiFi problems.
I've been bitten by this bug twice always after going away from the office w/o
disconnecting manually the wifi. Device hot and battery falling 2 bars per
hour.
After second time - and founding my N900 out of juice when I needed it!, I
decided to simply delete the office wifi and always use 3G connection... I will
reactivate WiFi to dig the bug out.
It doesn't appear always,next time it happens and I have time I'll do a search
for causes (i.e. top and all the hell)

If we look at bugs 6378, 5386, 5803, 6371 and at the resposenses of nokia 
employes there is no chance that this bug will be fixed any time soon.
So for people bitten by this bug this definitely transforms the N900 wonder
phone in something with the utility of a brick. I'm starting to regret
having bought it as seems to me as a product rushed to the  markets in an
unfinished and buggy state with immature driver software and basic missing
features. The users are used as beta testers for a yet to come next version.

(In reply to comment #39)
> If we look at bugs 6378, 5386, 5803, 6371 and at the resposenses of nokia 
> employes there is no chance that this bug will be fixed any time soon.
> So for people bitten by this bug this definitely transforms the N900 wonder
> phone in something with the utility of a brick. I'm starting to regret
> having bought it as seems to me as a product rushed to the  markets in an
> unfinished and buggy state with immature driver software and basic missing
> features. The users are used as beta testers for a yet to come next version.
> 

Yup, i know exactly what you mean and it totally sucks! 

I quote: "planned for Harmattan, not in the scope of Fremantle since it would
imply many changes and we prefer to concentrate on other priorities now.
"

Whats up with that? We bought a device with Fremantle so we can iron out the
bugs that will be fixed in Harmattan?! As soon as it takes some work it simply
won't be done! Here is another one: https://bugs.maemo.org/show_bug.cgi?id=6344
Look at comment #2

(In reply to comment #40)
> Whats up with that? We bought a device with Fremantle so we can iron out the
> bugs that will be fixed in Harmattan?! As soon as it takes some work it simply
> won't be done! Here is another one: https://bugs.maemo.org/show_bug.cgi?id=6344
> Look at comment #2

please, get your defective devices replaced, it will ease your mind.
in addition, contact nokia customer support by email, phone and snailmail and
start bothering at the right places. feel free to blog about these issues, use
twitter, facebook and all the social media that was used to create the hype
that made you buy the N900..

(In reply to comment #41)

> please, get your defective devices replaced, it will ease your mind.
> in addition, contact nokia customer support by email, phone and snailmail and
> start bothering at the right places. feel free to blog about these issues, use
> twitter, facebook and all the social media that was used to create the hype
> that made you buy the N900..

...And whatever you do, please do not discuss about it in bugzilla.

(In reply to comment #42)
> ...And whatever you do, please do not discuss about it in bugzilla.
...feel free to censor anything you dislike.

Comment 44 Andre Klapper 2009-12-17 13:48:57 UTC

(In reply to comment #43)
> (In reply to comment #42)
> > ...And whatever you do, please do not discuss about it in bugzilla.
> ...feel free to censor anything you dislike.

Tom, you don't get it at all.
It's not about censorship, it's about useful communication. Go to a forum for
unrelated postings, but don't waste everybody's time (also the time of the
developers that you want to fix your bug, maybe?) by triggering bugmail by
unhelpful comments that add no value at all to the bug.
Go to a forum instead.

Last warning.

@tom unless you can prove it's a hardware defect, isn't it more likely to be
software at this point, and so giving further information here is useful ?

Got a script done to load/unload wifi and stop the power drain.
It needs to be run  as root.
The script still lacks hildon desktop integration:
1) change the system try icon
2) set current connection as disconnected
3) a launcher for the desktop
4) .....
Help from the hildon desktop gurus is appreciated!!! ;-)
Let us get the job done and start using our wonder phone.

--------------------------------------------------------------------------------
#!/bin/sh
#
# Wlan module loader/unloader for N900
# by farmatito@tiscali.it GPL
#
if [ `lsmod | grep -c wl12xx` -gt 0 ] ; then
        # wl12xx module is loaded
        echo -n "Shutting down  wlan0 interface..."
        ifconfig wlan0 down
        if test $? -eq 0 ; then
                echo "done"
        else
                echo "failed"
                exit 1
        fi
        echo -n "Unloading wlan modules..."
        rmmod wl12xx
        if test $? -ne 0 ; then
                echo "failed"
                exit 1
        else
                rmmod mac80211
                if test $? -ne 0 ; then
                        echo "failed"
                        exit 1
                else
                        rmmod crc7
                        if test $? -ne 0 ; then
                                echo "failed"
                                exit 1
                        fi
                fi
        fi
        echo "done"
        if test -e /var/run/wlancond.pid ; then
                /etc/init.d/wlancond stop
        fi
else
        # wl1251 module is not loaded
        echo -n "Loading wlan modules..."
        modprobe wl12xx
        if test $? -eq 0 ; then
                echo "done"
        else
                echo "failed"
                exit 1
        fi
        echo -n "Calibrating wl1251.."
        /usr/bin/wl1251-cal 2>/dev/null 1>/dev/null
        if test $? -eq 0 ; then
                echo "done"
        else
              echo "failed"
                exit 1
        fi
        if test ! -e /var/run/wlancond.pid ; then
                /etc/init.d/wlancond start
        fi
fi
--------------------------------------------------------------------------------

Reply to comment #38 from Michele Giorgini
(https://bugs.maemo.org/show_bug.cgi?id=6615#c38)

> I've been bitten by this bug twice always after going away from the office w/o
disconnecting manually the wifi. Device hot and battery falling 2 bars per our.

This could be one reason, it fits in my case too. In addition I also had the
automatic reconnect to WLAN turned on (10 min polling time) when this battery
issue happened to me. Since then I've removed automatic reconnections and
always disconnect from WLAN before leaving the AP's range. (I also removed the
calendar widget from desktop, which is said to draw the battery.) I've now
tested open WLAN and encrypted (WPA2-PSK) networks and my battery lasts easily
a day with moderate use. Currently I've had the N900 connected to my WLAN for
2,5 hours (basicly idle though) and the hal's battery.charge_level.percentage
has dropped from 85 to 77.

I have the same issue with died battery after a short time WiFi usage.
Phone is warm. Battery last withing 5-6 hours in standby mode.

Have replaced to the new n900 today, nothing changed, bug is still here.

Problem description:
N900 with 1.2009.42-11 firmware.
Access point is "Cisco 871W".
You can use a phone without SIM card to reproduce this problem.

N900 firmware was reflashed in the Nokia service center, nothing changed.
After that this n900 was replaced to the new one, nothing changed again.

Note: I cannot reproduce this issue with "open" WiFi connection, without
authentification and encryption. If "security method" is WEP or WPA pre-shared
key or WPA with EAP battery dies within ~5-7 hours, it depends on the "WLAN
transmission power" settings. ~5 hours with 100mW, ~7 hours w/ 10mW

Internet connections settings:
Connect automatically - Always Ask
Search interval - Never
Network is hidden - YES
Network mode - Infrastructure
Security method - WPA pre-shared key

Advanced settings:
IP address - Static
WLAN transmission power - 10mW (battery last ~7 hours)
WLAN transmission power - 100mW (battery last ~5 hours)
Power saving - On (maximum)

Reproducing:
Enable WiFi connection for a couple of seconds than press "disconnect" in the
"select connection" menu.
Leave the phone in standby mode.

Fix this BUG please!

The script i've posted above does not always work so forget about it.
I've also tested a self compiled kernel with the latest
compat-wireless-2009-12-11
 wl12xx drivers. It builds and boots but the wl1251 modules seems not be able 
to initialize (detect?) the wifi card correctly.
I've tried to compile the sta_dk_4_0_4_32 driver from the android repository
but it doesn't support the rx51 board. Now I'm running out of ideas.
Some hints, advices, forecasts about when this bug will be fixed from
some nokia representatives would be nice.

Hi,

I read it and compare with my usage and I suspect that WiFi power usage is in
driver activity. In my case I see a regular message about losing beacon from
some bogus AP - I never use it. And it reports it all day, each second with
calm intervals around 10-20secs.

Exactly, the message in /var/log/syslog is:

Dec 26 .... kernel: [....] wlan0: driver reports beacon loss from AP cf1bb52c -
sending probe request

(the "cf1bb52c" is reported always, independent from real location and the
connected SSID. And it is reported even N900 sitting in 3 foots from WiFi
router - it is not my router at home or at work)

Of course, any WiFi transmission sucks the power. I browsed the directories
under /var/lib/gconf I don't find any unaccounted connection. I guess it is
some rudiments in wl12xx driver from Nokia...

The message is from wlan daemon and it is not seen in dmesg, so to see it you
should install syslogd/klogd package.

Correction,

(In reply to comment #51)

> Dec 26 .... kernel: [....] wlan0: driver reports beacon loss from AP cf1bb52c -
> sending probe request

Looking into source code of mac80211 - instead of cf1bb52c it should be MAC
address of AP. Something like 00:1c:df:67:1f:ac. Looks like kernel 'printk()'
doesn't understand properly a format tag '%pM'.

However, I believe the source of short battery life is in often WiFi
transmission even in idle state. I use at home Linksys WRT54Gv8 / GSv7 with
DD-WRT v24 (05/24/08) micro but I don't know the router at work (N900 reports
the same "sending probe request").

Sorry for bothering all you, 

but I just read a lot of stuff about this issue and it looks like at some point
wl12xx and mac80211 drivers don't agree about filtering beacon messages from
AP. WiFi chip is configured to filter beacon signals but low-level driver
reports the beacon loss to mac80211 and it issues a connection revival
keepalive to AP. 

Text from http://linuxwireless.org/mac80211book/ch08.html -

"Some hardware have beacon filter support to reduce host cpu wakeups which will
reduce system power consumption. It usually works so that the firmware creates
a checksum of the beacon but omits all constantly changing elements (TSF, TIM
etc). Whenever the checksum changes the beacon is forwarded to the host,
otherwise it will be just dropped. That way the host will only receive beacons
where some relevant information (for example ERP protection or WMM settings)
have changed.

Beacon filter support is advertised with the IEEE80211_HW_BEACON_FILTER
hardware capability. The driver needs to enable beacon filter support whenever
power save is enabled, that is IEEE80211_CONF_PS is set. When power save is
enabled, the stack will not check for beacon loss and the driver needs to
notify about loss of beacons with ieee80211_beacon_loss."

So, Nokia?

(Interesting, I was able to stop a constant sending of probe request on beacon
loss then I just tried to connect to some neighbor WPA protected network and
refuse to give a key. Driver stopped issuing a probe... I still measuring a
battery life).

(In reply to comment #53)
> Sorry for bothering all you, 
> 
> but I just read a lot of stuff about this issue and it looks like at some point
> wl12xx and mac80211 drivers don't agree about filtering beacon messages from
> AP. WiFi chip is configured to filter beacon signals but low-level driver
> reports the beacon loss to mac80211 and it issues a connection revival
> keepalive to AP. 
> 
> Text from http://linuxwireless.org/mac80211book/ch08.html -
> 
> "Some hardware have beacon filter support to reduce host cpu wakeups which will
> reduce system power consumption. It usually works so that the firmware creates
> a checksum of the beacon but omits all constantly changing elements (TSF, TIM
> etc). Whenever the checksum changes the beacon is forwarded to the host,
> otherwise it will be just dropped. That way the host will only receive beacons
> where some relevant information (for example ERP protection or WMM settings)
> have changed.
> 
> Beacon filter support is advertised with the IEEE80211_HW_BEACON_FILTER
> hardware capability. The driver needs to enable beacon filter support whenever
> power save is enabled, that is IEEE80211_CONF_PS is set. When power save is
> enabled, the stack will not check for beacon loss and the driver needs to
> notify about loss of beacons with ieee80211_beacon_loss."
> 
> So, Nokia?
> 
> (Interesting, I was able to stop a constant sending of probe request on beacon
> loss then I just tried to connect to some neighbor WPA protected network and
> refuse to give a key. Driver stopped issuing a probe... I still measuring a
> battery life).
> 

One of the experiments I've done in the attempt to fix my useless wonder phone 
was to use the firmware shipped with the HTC G1 Fw1251r1c.bin which loads and
works fine and if I recall correctly doesn't show beacon loss messages. The
battery drain issue still was there the same. There must be more than one bug,
I think there are more issues:
1) the driver wl12xx was immature code and in fact there are loads of patches
   posted for inclusion from the same author for fixing bugs and
   adding missings features.
2) the design is bad as it is missing key features like a gui toggle to turn 
   the wifi radio off (I suspect due to the fact that the current driver
doesn't
   permit it, in the sense that even if you rmmod the modules manually and 
   reinsert them when needed sometimes the wifi chip doesn't wakeup correctly)
3) the use of non standard software like wlancond  (sometimes just restarting
   it through "/etc/init.d/wlancond restart" is sufficient to trigger the
   watchdog and reboot the phone).
4) the need of nokia to not miss the Xmas sales forced them to rush it to the 
   markets in an unfinished state.
5) the absence from the bug list of nokia representatives and the bugs staying 
   there forever as unassigned.

(In reply to comment #52)
> Correction,
> 
> (In reply to comment #51)
> 
> > Dec 26 .... kernel: [....] wlan0: driver reports beacon loss from AP cf1bb52c -
> > sending probe request
> 
> Looking into source code of mac80211 - instead of cf1bb52c it should be MAC
> address of AP. Something like 00:1c:df:67:1f:ac. Looks like kernel 'printk()'
> doesn't understand properly a format tag '%pM'.
> 
> However, I believe the source of short battery life is in often WiFi
> transmission even in idle state. I use at home Linksys WRT54Gv8 / GSv7 with
> DD-WRT v24 (05/24/08) micro but I don't know the router at work (N900 reports
> the same "sending probe request").
> 

BTW the beacon loss message you have is exactly the same as the one I've got:

wlan0: driver reports beacon loss from AP cf1bb52c - sending probe request

even the AP  cf1bb52c is the same. So I'm starting to suspect this bug has
nothing to do with the router used but just with the faulty kernel driver or
firmware blob.

Created an attachment (id=1858) [details]
Attempt to use sysfs to switch wifi chip on/off

Attempt to use sysfs to switch wifi chip on/off

If somebody with kernel hacking experience would like to help I'm trying to
implement a sysfs switch to turn the wifi chip on/off. Turning it off (the easy
part works) but I'm not able to figure out the correct way to reinitialize the
wifi chip and make it and wlancond happy.

Comment 58 Neil MacLeod 2009-12-27 19:16:04 UTC

SOFTWARE VERSION:
2.2009.51-1

As per my comment 36, my N900 would have a flat battery at 3pm having been
fully charged at 9am, and this with only very light usage on 3G in central
London.

I'm now fortunate enough to be testing firmware 2.2009.51-1, and I'm very happy
to report that with this firmware by 3pm the battery now stands at 80%
remaining, and should last a full "working day" of light to moderate usage. By
8pm the same day the battery had about 30% remaining[1]. It has even lasted
beyond 24 hours, but only just.

I would now say the battery lifetime with 2.2009.51-1 is equivalent to that of
a Nokia N85, possibly slightly better.

The point of this post is only to say: hold on, a fix is coming (at least for
the problems I had, which hopefully are the same as the rest of you are
having).

1. Approximate usage during the period 9am-8pm: Taking/making 40 minutes of
calls, 5 photographs with flash, 1 hour of web surfing over 3G, email checks
every 30 minutes (POP account) and receipt of about 20 emails, GoogleTalk and
Skype presence enabled, RSS feed updates every couple of hours (about 10 feeds
- BBC, Times, Engadget etc.), WiFi scanning every 30 minutes.

(In reply to comment #58)
> SOFTWARE VERSION:
> 2.2009.51-1
> 
> As per my comment 36, my N900 would have a flat battery at 3pm having been
> fully charged at 9am, and this with only very light usage on 3G in central
> London.

Thank you, Neil.

Do you see the messages about beacon loss now? It looks like this bug was
discovered last spring in generic Linux kernel (2.6.30+) but I don't know was
it fixed or not. I suspect - not, because it is meaningless for desktop.

Comment 60 Neil MacLeod 2009-12-28 03:40:13 UTC

(In reply to comment #59)
> Do you see the messages about beacon loss now? It looks like this bug was
> discovered last spring in generic Linux kernel (2.6.30+) but I don't know was
> it fixed or not. I suspect - not, because it is meaningless for desktop.
> 

Can't see any warnings in 2.2009.51-1 with my Linksys WRT610N AP, but then I
don't know if I had any such beacon loss warnings with 1.2009.42-11 so I can't
say for sure if this particular issue is fixed or not.

Comment 61 Eero Tamminen 2009-12-28 12:38:04 UTC

> 3) the use of non standard software like wlancond  (sometimes just restarting
>   it through "/etc/init.d/wlancond restart" is sufficient to trigger the
>   watchdog and reboot the phone).

I don't know anything about wlancond, but in Maemo5, device services are
started with Upstart, not by sysvinit scripts (many of the old sysvinit scripts
are still in the device for legacy reasons, they will be cleaned out in
Maemo6).

Use something like "stop wlancond; start wlancond" instead; there seem to be
some other services depending on wlancond (see "grep wlancond /etc/event.d/*").

Comment 62 Neil MacLeod 2009-12-30 05:27:31 UTC

Created an attachment (id=1874) [details]
Beacon loss messages *are* present in 2.2009.51-1

The N900 has been connected all day to a Linksys WRT610N v1 (firmware 1.00.02
B10) with the 2.4GHz radio in "Mixed" mode (ie. b/g/n).

Other points to note:

1) "sending LOWSIGNAL"/"sending HIGHSIGNAL" often repeat endlessly, every 7
seconds (excessive logging?)
2) There are several messages present that reference "AP cf1bb52c", which
should be cleaned up/fixed

I've experienced lots of authentication/deauthentication problems today and
pretty cr@ppy wireless - maybe one of my neighbours got a new wireless router
for Christmas! However battery life is still good, as per my previous comment.

(In reply to comment #62)
> Created an attachment (id=1874) [details] [details]
> Beacon loss messages *are* present in 2.2009.51-1
> 
> The N900 has been connected all day to a Linksys WRT610N v1 (firmware 1.00.02
> B10) with the 2.4GHz radio in "Mixed" mode (ie. b/g/n).
> 
> Other points to note:
> 
> 1) "sending LOWSIGNAL"/"sending HIGHSIGNAL" often repeat endlessly, every 7
> seconds (excessive logging?)
> 2) There are several messages present that reference "AP cf1bb52c", which
> should be cleaned up/fixed
> 
> I've experienced lots of authentication/deauthentication problems today and
> pretty cr@ppy wireless - maybe one of my neighbours got a new wireless router
> for Christmas! However battery life is still good, as per my previous comment.
> 

H,
can you try to use HTC G1's firmware (attached).
Just rename it wl1251-fw.bin.
If I recall correctly I had no beacon loss messages at all
when I tested it. It was generally less verbose 
but wifi worked well despite the battery drain issue.

Created an attachment (id=1875) [details]
HTC G1 firmware for testing purpose

(In reply to comment #8)
> I've tried to find some logic on this issue for a while, and I cannot find any.
> This problem seems to be random, but sometimes if I leave calendar software on
> (I have ~60-70 classes set there), it raises CPU usage to ~70% (measured using
> top on terminal). After restarting calendar, sometimes this issue stays, but if
> you restart device, it goes away. Most of the time, calendar doesn't consume
> cpu so heavily.

In regard to the "Calendar drain", please have a look at bug 6687 comment #4.
Not a final solution, but at least a workaround.

Comment 66 Neil MacLeod 2009-12-31 00:08:29 UTC

(In reply to comment #64)
> Created an attachment (id=1875) [details] [details]
> HTC G1 firmware for testing purpose
> 

OK I've installed this temporarily, will probably need to leave it a day or two
to in order to give enough time for beacon message to have appeared.

Just to note that your bin is Rev 4.0.4.3.5 (EU region) whereas the version I
replaced and that shipped with 2.2009.51-1 is Rev 4.0.4.3.6 (US region).

Comment 67 Neil MacLeod 2010-01-01 04:26:58 UTC

(In reply to comment #63)
> H,
> can you try to use HTC G1's firmware (attached).
> Just rename it wl1251-fw.bin.
> If I recall correctly I had no beacon loss messages at all
> when I tested it. It was generally less verbose 
> but wifi worked well despite the battery drain issue.
> 

OK, loads of beacon loss messages from the HTC G1 firmware today, going back to
the stock 2.2009.51-1 firmware. Suggest you open another bug for this if you
are concerned about it - not really sure it's related to battery lifetime
(which is much improved in 51-1)

(In reply to comment #67)

> OK, loads of beacon loss messages from the HTC G1 firmware today, going back to
> the stock 2.2009.51-1 firmware.

Was it at the same time or it lasted some long time?
(Short time means nothing because it can be just regular loss of RF receiption
due to different reasons).

Comment 69 Neil MacLeod 2010-01-01 04:50:39 UTC

(In reply to comment #68)
> 
> Was it at the same time or it lasted some long time?
> (Short time means nothing because it can be just regular loss of RF receiption
> due to different reasons).
> 

"Beacon loss" messages occurred over a period of about 1.5 hours (Jan 1
00:53:53 to Jan 1 02:23:58, 139 messages) which appears to disprove your belief
that the HTC firmware doesn't generate these messages, when obviously it does.

Please open another bug as further discussion is not relevant here, and is
generating bugspam.

The SmartReflex power saving feature of the OMAP processor is disabled by
default on the n900.  To enable it:

echo 1 > /sys/power/sr_vdd1_autocomp
echo 1 > /sys/power/sr_vdd2_autocomp

You can also enable it by editing /etc/pmconfig and changing the appropriate
values to 1, and rebooting.

I've been logged in to my wifi accounts for 10+ hours now, with GPS on, and the
battery is only down by about 1/3.

Some power saving can also be achieved by setting your status to be offline and
disabling networking.

Comment 71 Neil MacLeod 2010-01-03 04:08:42 UTC

(In reply to comment #70)
> The SmartReflex power saving feature of the OMAP processor is disabled by
> default on the n900.  To enable it:
> 
> echo 1 > /sys/power/sr_vdd1_autocomp
> echo 1 > /sys/power/sr_vdd2_autocomp

Interesting... the value for this feature is still 0 in 2.2009.51-1, so
improved battery life can be achieved in other ways, although official
SmartReflex support could be icing on the cake.

Apparently the SmartReflex feature is dependent on the characteristics of the
OMAP silicon, and may therefore be unstable on some devices[1].

1. http://markmail.org/message/xcnv77dnot57eqhj

So is it a good or bad idea to make these changes on the N900?

(In reply to comment #71)
> (In reply to comment #70)
> > The SmartReflex power saving feature of the OMAP processor is disabled by
> > default on the n900.  To enable it:
> > 
> > echo 1 > /sys/power/sr_vdd1_autocomp
> > echo 1 > /sys/power/sr_vdd2_autocomp
> 
> Interesting... the value for this feature is still 0 in 2.2009.51-1, so
> improved battery life can be achieved in other ways, although official
> SmartReflex support could be icing on the cake.
> 
> Apparently the SmartReflex feature is dependent on the characteristics of the
> OMAP silicon, and may therefore be unstable on some devices[1].
> 
> 1. http://markmail.org/message/xcnv77dnot57eqhj
>

(In reply to comment #70)
> The SmartReflex power saving feature of the OMAP processor is disabled by
> default on the n900.  To enable it:
> 
> echo 1 > /sys/power/sr_vdd1_autocomp
> echo 1 > /sys/power/sr_vdd2_autocomp
> 

Set it, around 6h idle and some web was OK, then start setup mail account and
got HW watchdog reboot (32wd_to - see bug 6334).

Before that never seen this kind of reboot (I have N900 a month). But it was my
first work with E-mail client.

I set this, and then tried both my IMAP account and (broken due to another bug)
Exchange sync (Google) account.

No reboot, current public firmware.

Wonder why this isn't on be default though...

On my phone this happens if I power on the phone when it is connected to
charger.

Steps to reproduce:
1. power off the phone (or empty the battery so phone powers off automatically)
2. connect charger
3. wait few seconds and power on
4. enter pin code
5. let battery charge fully
6. disconnect charger and use phone as you normally do

=> battery runs out much faster than normally

reproduced this 2 of 2 tries. If I power on / reboot the phone when it is not
connected to charger battery lasts about 5 times longer.

(In reply to comment #74)
> I set this, and then tried both my IMAP account and (broken due to another bug)
> Exchange sync (Google) account.
> 
> No reboot, current public firmware.
> 
> Wonder why this isn't on be default though...
> 

I'm getting frequent reboots when I enable the SmartReflex power saving
feature.

Define frequent. Was the device idle or doing something both up to the reboot
and when it happened ?

Can I also assume you've flipped the setting back to 0 (or rebooted) and the
problem goes away ?

(In reply to comment #77)
> Can I also assume you've flipped the setting back to 0 (or rebooted) and the
> problem goes away ?
> 

In my case set back to 0s, switch OFF-ON, 10h and a lot of joy with different
e-mail accounts, PDF attachments etc and no problem. Will keep at this some
time to be sure that it is not e-mail+gstreamer problem and then will try
again. But I guess it may be a power consumption problem during SGX graphic
work + 3G access.

(I use just standard 42-11).

(In reply to comment #70)
> The SmartReflex power saving feature of the OMAP processor is disabled by
> default on the n900.  To enable it:
> 
> echo 1 > /sys/power/sr_vdd1_autocomp
> echo 1 > /sys/power/sr_vdd2_autocomp
> 
> You can also enable it by editing /etc/pmconfig and changing the appropriate
> values to 1, and rebooting.
> 
> I've been logged in to my wifi accounts for 10+ hours now, with GPS on, and the
> battery is only down by about 1/3.
> 
> Some power saving can also be achieved by setting your status to be offline and
> disabling networking.
> 

Turning on SmartReflex hasn't caused any reboots for me and seems to be working
well.

My battery used to last about 12 hours before - and now at the 12 hour stage
with the same usage pattern I'm at 45% charged according to lshal.

The wifi seems to disconnect a bit more when I have a weak signal, but I might
be imagining it, as it was only three times instead of not at all.

Comment 80 Neil MacLeod 2010-01-04 14:22:49 UTC

Just a suggestion: as battery lifetime is already significantly improved in
2.2009.51-1 without the aid of SmartReflex, it might be more appropriate to
hive off the SmartReflex discussion into a separate bug report (suggesting that
it be enabled by default) where Nokia engineers can respond with pros & cons or
arguments for/against the request, without fear of spamming this bug which
appears to be fixed already (in 2.2009.51-1).

SmartReflex bug: https://bugs.maemo.org/show_bug.cgi?id=7633

(In reply to comment #75)
> On my phone this happens if I power on the phone when it is connected to
> charger.
> 
> Steps to reproduce:
> 1. power off the phone (or empty the battery so phone powers off automatically)
> 2. connect charger
> 3. wait few seconds and power on
> 4. enter pin code
> 5. let battery charge fully
> 6. disconnect charger and use phone as you normally do
> 
> => battery runs out much faster than normally
> 
> reproduced this 2 of 2 tries. If I power on / reboot the phone when it is not
> connected to charger battery lasts about 5 times longer.
> 

The last two times that I charged my phone, the battery started to drain fast.
I haven't had the time to try to reproduce it, but *I think* that this happens
if I unplug the charger off the wall first, then off the phone. Could you try
and see if that happens in your phone as well, kiuzeppe?

(In reply to comment #82)
> The last two times that I charged my phone, the battery started to drain fast.
> I haven't had the time to try to reproduce it, but *I think* that this happens
> if I unplug the charger off the wall first, then off the phone. Could you try
> and see if that happens in your phone as well, kiuzeppe?

Same problem, no time to try. This is my primary phone and I need working
phone.
However, I don't think that this is the case with my device. I leave charger on
the wall always.

(In reply to comment #70)
> The SmartReflex power saving feature of the OMAP processor is disabled by
> default on the n900.  To enable it:
> 
> echo 1 > /sys/power/sr_vdd1_autocomp
> echo 1 > /sys/power/sr_vdd2_autocomp
> 
> You can also enable it by editing /etc/pmconfig and changing the appropriate
> values to 1, and rebooting.
> 
> I've been logged in to my wifi accounts for 10+ hours now, with GPS on, and the
> battery is only down by about 1/3.
> 
> Some power saving can also be achieved by setting your status to be offline and
> disabling networking.
> 

it works. I don't know the technical adv / dis adv of it. But it has improved
my battery life double the time. it lasts at least for a day now. Thanks.

(In reply to comment #84)
> (In reply to comment #70)
> > The SmartReflex power saving feature of the OMAP processor is disabled by
> > default on the n900.  To enable it:
> > 
> > echo 1 > /sys/power/sr_vdd1_autocomp
> > echo 1 > /sys/power/sr_vdd2_autocomp
> > 
> > You can also enable it by editing /etc/pmconfig and changing the appropriate
> > values to 1, and rebooting.
> > 
> > I've been logged in to my wifi accounts for 10+ hours now, with GPS on, and the
> > battery is only down by about 1/3.
> > 
> > Some power saving can also be achieved by setting your status to be offline and
> > disabling networking.
> > 
> 
> it works. I don't know the technical adv / dis adv of it. But it has improved
> my battery life double the time. it lasts at least for a day now. Thanks.
> 

I want to test this , but somebody can explain to me , how disable this if my
phone don't stop to reboot ? thanks

@fw: just reboot, or run again with zero, not ones.

(In reply to comment #86)
> @fw: just reboot, or run again with zero, not ones.
> 

thx :)

Hi,

Just adding that I also bumped into this situation on new years eve in the
following situation:

22:30  battery at about 50%, no apps open
   - I opened the "Conversations" and chose "New SMS"
   - wrote my new year greetings sms ready for sending 
   - added multiple recipients from the contact list.
   - left the phone in keylock (dark screen) to wait for the midnight

0:00  Phone was dead when I tried to send the messages
  => 50% of battery wasted in less than 1.5h doing nothing

Comment 89 Eero Tamminen 2010-01-11 15:12:23 UTC

(Hard to reproduce) bug 6868 may also contribute to this issue, but is easy to
miss from the "top" output.  When you hit this issue, you could check whether
"strace -f -p $(pidof pulseaudio)" e.g. over SSH (so that you don't cause
pulseaudio activity due to screen or key clicks) shows up anything.

Hello,

I suddenly started to get the same issue.
Everything was fine since one month, then one day with the battery at 50% and
having just used wifi, I went away for 2h and then found my N900 battery dead.

Since then I often got the battery drainage problem after disconnecting wifi.
I tried the 'ifconfig wlan0 down' but no luck.
The only sure thing for me is to reboot after using wifi.

P.S. : Very easy to detect the battery drainage, I just had to touch the phone,
it gets very warm in 20 mn !

Comment 91 Andre Klapper 2010-01-11 17:50:26 UTC

************************************************************************
Please see comment 89 before posting and please avoid "me too" postings.
************************************************************************

Ok I forgot the strace, would do it next time.
I _do_ have read the other post.
I should have emphasize more that my problem suddenly appears after one month
of normal battery behavior (used a lot of different wifi router) and even one
reflash and different SIM cards used.
Now that the bug has been triggered once, it is happening even with the wifi
routers I have previously used during my 'normal' month.

I do not recall having seen such particular behavior in the previous post
(normal battery behavior then quick battery drainage).

With 1.2009.44-1 patch, the bug still exists. I also noticed few additional
things about it. When using ping (1 s interval) to keep Wi-Fi connection open,
the battery drainage is relatively low. After closing the Wi-Fi connection,
there is heavy battery drainage. Repeat Wi-Fi connection open with ping and
again relatively low battery drainage. So, a partial fix is to keep Wi-Fi
connection on with constant ping so it won't get disconnected due to
inactivity. This will give estimated 15-30 hours of battery time for idle
phone.

Did not install strace to look for pulseaudio, but did have a very good and
long look at top. During one minute time, CPU was at about 95 % idle and never
went to less than 90 % idle. Pulseaudio process never showed up in the high end
of top. As such, I'm quite sure any problems causing excessive CPU usage and
thus draining battery are not the case here.

(In reply to comment #93)
> With 1.2009.44-1 patch, the bug still exists. I also noticed few additional
> things about it. When using ping (1 s interval) to keep Wi-Fi connection open,
> the battery drainage is relatively low. After closing the Wi-Fi connection,
> there is heavy battery drainage. Repeat Wi-Fi connection open with ping and
> again relatively low battery drainage. So, a partial fix is to keep Wi-Fi
> connection on with constant ping so it won't get disconnected due to
> inactivity. This will give estimated 15-30 hours of battery time for idle
> phone.

Wow, great! It points to beacon loss problem and links it to battery drain (see
#51). In constant ping environment there is no beacon loss because timeout
doesn't expire. But in it's absence WiFi initiates re-negotiation and that
actually includes scanning of channels and other stuff.

At least, it is my guess.

Confirmed. Bug still exists with firmware 1.2009.44-1.

Comment 96 Tim Samoff 2010-01-12 15:49:21 UTC

Just had this happen yesterday with an interesting use case:

1. Had a battery at about 80%.
2. Started to install an app from HAM.
3. The app had a secondary dialog that asked me to confirm something  (I think
it was the update to PixelPipe).
4. I didn't confirm the dialog, but just let the device go to sleep.
5. Woke the device up about an hour later and the battery was at 10%.

I updated about 5 apps, so I'm not positive if it was PixelPipe, but it was
definitely on of the Maemo "official" apps. I'll try to figure out for sure.

Comment 97 Eero Tamminen 2010-01-12 17:20:02 UTC

(In reply to comment #93)
> With 1.2009.44-1 patch, the bug still exists.

44.1 is just an update to fix some issues related to SSU disk usage before the
"real" update comes.


> Did not install strace to look for pulseaudio, but did have a very good and
> long look at top. During one minute time, CPU was at about 95 % idle and
> never went to less than 90 % idle. Pulseaudio process never showed up in
> the high end of top. As such, I'm quite sure any problems causing excessive
> CPU usage and thus draining battery are not the case here.

Even things that wakeup once a sec (constantly) cause very large use time drop
(from several days of idle to less than day). Those show up in top with
something like 0-2% CPU usage.

Created an attachment (id=1965) [details]
Control Panel applet to enable/disable Wifi

Control Panel applet to enable/disable Wifi

Created an attachment (id=1966) [details]
Control Panel applet to enable/disable Wifi (Source)

Control Panel applet to enable/disable Wifi (Source)

The above wifi-switcher deb allows (with the latest firmware 1.2009.44.1)
to enable/disable wifi and thus should stop battery drain.
Please test and report if it works for you. Hints, improvements and patches
are welcome. Enjoy.
Tito

I tried the statusbar app and switched WiFi on and off many times. So far no
issues, works like a charm. A small indicator if WiFi is on or off would be a
great improvement.

thank you for the small app :)

Comment 102 Andre Klapper 2010-01-14 12:32:55 UTC

Today Nokia released the Maemo5 update version 2.2009.51-1 for public (also
called "PR1.1" sometimes).
If you have some time we kindly ask you to test again if the problem reported
here still happens in this new version - just leave a comment (and feel free to
update the "Version" field to the new version if it's still a problem).

Tested with PR1.1 and the bug still occurs.

As another note, I tested another Wi-Fi router a friend of mine had that didn't
exhibit the bug on my friends N900. The bug was not present on my N900 either.
So it is related to the Wi-Fi router used. This test was with PR1.01.

Mine is D-Link DGL-4300 and my friend has Buffalo WZR-AG300NH. Some weeks ago
(PR1.0), I tried matching my Wi-Fi router settings to those of my friend's
Wi-Fi router. It did not help. Currently the settings are mostly identical,
except my Wi-Fi router is in invisible mode. Both use WPA-personal,
WPA2-preferred.

I had invisible mode Wi-Fi connection saved to N900 when trying my friend's
Wi-Fi router without triggering the bug. Also my Wi-Fi router causes the bug
when on visible mode (both on router and on N900 and N900 rebooted after
settings change). As such, it seems that visible/invisible status had no
relevance to the problem whatsoever.

Confirmed for 2.2009.51-1. Router is a Linksys WAG160N ver.1 hardware.

2.2009.51-1 and Cisco 871W nothing changed, bug is present.

2 Tito,

Thank you for the applet, it works fine with Cisco 871W and WPA pre-shared key
security!
Two things to note:
- when I first tap on WiFi switcher nothing happens. Only second tap brings on
"Select connection" menu.
- after switching off WiFi through the WiFi switcher I'm not able to see any
WiFi networks if I tap "Internet connection" applet, only GPRS/EDGE/3G are
visible.

2 Zeed
First tap disables wifi, nothing is shown here, maybe will change that so that
a notification is shown.
Select Connection dialog is shown when wifi is re-enabled.
Should add also some try icon...

Fully charged battery this morning, then connected to Dynamode R-ADSL-C4W-EG
for 5 minutes. I was punished for this indiscretion with a flat battery 4 hours
later.

Installed PR1.1 and rebooted. Fully charged battery, then connected to Dynamode
R-ADSL-C4W-EG for 5 minutes. I was punished for this indiscretion with a flat
battery 4 hours later.

Created an attachment (id=2001) [details]
Control Panel applet to enable/disable Wifi 0.0.3

Control Panel applet to enable/disable Wifi 0.0.3

* Added tray icon when wlan is off

For the brave hit by this bug to test....

Created an attachment (id=2003) [details]
Control Panel applet to enable/disable Wifi 0.0.3 (Source)

Control Panel applet to enable/disable Wifi 0.0.3 (Source)

For those who want to contribute or improve it.

(In reply to comment #110)
> Created an attachment (id=2001) [details] [details]
> Control Panel applet to enable/disable Wifi 0.0.3
> 
> Control Panel applet to enable/disable Wifi 0.0.3
> 
> * Added tray icon when wlan is off
> 
> For the brave hit by this bug to test....
> 

It's good, I think it would be good if you stick this into Extras

Control Panel applet works great with temporary solution.

When i'am done with browsing etc, 
1 turning off the wifi connection with build in turn off function. 
2 Control Panel applet wifi shut off and ON again, no drain leakage after
turning it too original state.

After all i don't need too reboot the device anymore!

ps.Thanks too the maker of Control Panel applet!

Can confirm that this bug is also present in the latest firmware PR1.1. This
bug is a major show stopper and needs to be looked into urgently. To run around
looking for a charging point every couple of hours does not help!! And I only
use 2G internet connection, not even wifi.

I can also confirm that if used only as a phone the battery lasts for about
10-12 hours but if any  type of email (modest/nokia messaging) is turned on the
battery just about crawls to 5-6 hours time. This I guess happens since the
internet connection is always on and drains the battery. It would help a lot if
bug 5422 is fixed which automatically disconnects internet connection (2G/3G)
once the activity (email/maps) is done. The automatic disconnection of inactive
network connections (2G/3G) greatly extended battery time in N95 and other
Symbian phones.

Comment 115 ext-jason.rudd@nokia.com 2010-01-18 18:14:52 UTC

Could reporters confirm whether they are using Static- or Dynamic-IP please?

https://bugs.maemo.org/show_bug.cgi?id=6615#c49

I use a static-ip adress, 

IPv4-adres: 192.168.1.7
IPv4-subnetmasker: 255.255.255.0
IPv4-standaardgateway: 192.168.1.1
IPv4 DNS-servers: 62.45.45.45
                  62.45.46.46

I use the Wifi Switcher now that works perfect without rebooting.

I use static ip on my WAG160N:
IP     : 192.168.1.106
NETMASK: 255.255.255.0
GATEWAY: 192.168.1.1
DNS    : 192.168.1.1

Comment 119 Markus Silvan 2010-01-19 10:24:00 UTC

Putting something like this to /etc/network/if-post-down.d/ should solve the
issue. Can reporters confirm that?

#! /bin/sh
set -e

if [ "$MODE" != stop ]; then
    exit 0
fi

if [ "$ICD_CONNECTION_TYPE" != WLAN_INFRA && "$ICD_CONNECTION_TYPE" !=
WLAN_ADHOC ]; then
    exit 0
fi

ifconfig $IFACE down

exit 0

(In reply to comment #119)
> Putting something like this to /etc/network/if-post-down.d/ should solve the
> issue. Can reporters confirm that?
> 
> #! /bin/sh
> set -e
> 
> if [ "$MODE" != stop ]; then
>     exit 0
> fi
> 
> if [ "$ICD_CONNECTION_TYPE" != WLAN_INFRA && "$ICD_CONNECTION_TYPE" !=
> WLAN_ADHOC ]; then
>     exit 0
> fi
> 
> ifconfig $IFACE down
> 
> exit 0
> 

There are 2 files present in,

/etc/network/if-post-down.d/

zz_enable_icmp_echo_reply
zz_proxy_unset

I dont understand, how can i add/modify the lines? if i add a new file the file
must be named and the text added in? but how

Comment 121 Markus Silvan 2010-01-19 11:13:35 UTC

> I dont understand, how can i add/modify the lines? if i add a new file the file
> must be named and the text added in? but how
> 

Just add a new file, make it executable and add those lines to that file.
I named the file "zz_static_ip_if_down".

(In reply to comment #121)
> > I dont understand, how can i add/modify the lines? if i add a new file the file
> > must be named and the text added in? but how
> > 
> 
> Just add a new file, make it executable and add those lines to that file.
> I named the file "zz_static_ip_if_down".
> 

I'am currently testing it now, 
Time tested connection: 30 minuts after shuttdown, drainage less then 2%
I enable/disable the connection with standard wifi/wlan control for now. NOT
with wifi swither (made by farmatito@tiscali.it) currently NO DRAINAGE
anymore!!!  its BUSTED !?!

Comment 123 Andre Klapper 2010-01-19 12:49:35 UTC

(In reply to comment #122)
> NOT with wifi swither (made by farmatito@tiscali.it) currently NO DRAINAGE
> anymore!!!  its BUSTED !?!

I don't understand what you're writing here, and if it's related at all.
Avoiding capitalization and being totally exact will help.

What is the implication of not actually down'ing the interface ?

(In reply to comment #119)
> Putting something like this to /etc/network/if-post-down.d/ should solve the
> issue. Can reporters confirm that?
> 
> #! /bin/sh
> set -e
> 
> if [ "$MODE" != stop ]; then
>     exit 0
> fi
>


This line looks suspicious to me: how can the connection be != WLAN_INFRA _and_
!= WLAN_ADHOC. Shouldn't it be || rather than &&. Seems to me ifconfig will be
not be reached for WLAN_INFRA or WLAN_ADHOC.
BTW: could we do ifconfig down systematically for WLAN_* on disconnect?
PS: where can I find a list of all values of $ICD_CONNECTION_TYPE?


> if [ "$ICD_CONNECTION_TYPE" != WLAN_INFRA && "$ICD_CONNECTION_TYPE" !=
> WLAN_ADHOC ]; then
>     exit 0
> fi
> 
> ifconfig $IFACE down
> 
> exit 0
>

Using static IP on the Wi-Fi router with bug occuring. On the Wi-Fi router of
my friend there is dynamic IP and no bug occuring.

(In reply to comment #125)

> This line looks suspicious to me: how can the connection be != WLAN_INFRA _and_
> != WLAN_ADHOC. Shouldn't it be || rather than &&. 

You are tired at night :)

Expression ((a != X) || (a != Y)) is TRUE anytime (assuming X != Y)

Tested out the dynamic/static IP case. On my Wi-Fi router I had static IP and
the bug occured. Changed it to dynamic IP and no more bug. Haven't tested the
code to fix problem with static IP.

So, the bug seems to be only about static IP and nothing else.

(In reply to comment #127)
> (In reply to comment #125)
> 
> > This line looks suspicious to me: how can the connection be != WLAN_INFRA _and_
> > != WLAN_ADHOC. Shouldn't it be || rather than &&. 
> 
> You are tired at night :)
> 
> Expression ((a != X) || (a != Y)) is TRUE anytime (assuming X != Y)
> 

Ops.... I see :-(

if [ "$ICD_CONNECTION_TYPE" = WLAN_INFRA || "$ICD_CONNECTION_TYPE" = WLAN_ADHOC
]; then
       ifconfig $IFACE down
fi

Would be easier to read IMO, if i understand it right.
Will test the script tonight.

zz_static_ip_if_down fix works fine.
Can't say if full wifi module unloading saves  more battery yet.

The change of the script from && too || triggered the drainage bug again.
I'am no developer but the script with && works for me.

Ok, looks like this workaround https://bugs.maemo.org/show_bug.cgi?id=6615#c119
solved this problem.
Hurray:)

After one day and one night of testing with the zz_static_ip_if_down fix
with my normal usage pattern I can say that it indeed fixes the fast battery
drain bug, but power consumption is still twice as fast vs. wl12xx module 
unloading. I think I will continue to use my hacky control panel applet.
Will test if this fix and the control panel applet are compatible and play
nicely together.

Comment 134 ext-jason.rudd@nokia.com 2010-01-20 16:00:27 UTC

"ifconfig wlan0 down" cuts the power to the wlan radio in all implementations I
have seen.

rmmod deletes a software driver, sensibly in this implementation the power is
cut to the wlan radio also like this. However you will save no more power and
have to reload the when next needed.

Created an attachment (id=2069) [details]
Control Panel applet to enable/disable Wifi 0.0.4

Control Panel applet to enable/disable Wifi 0.0.4

Created an attachment (id=2070) [details]
Control Panel applet to enable/disable Wifi 0.0.4 (Source)

Control Panel applet to enable/disable Wifi 0.0.4 (Source)

I've uploaded latest version of wifi switcher control panel applet if somebody
prefers to use it rather than the proposed _working_ fix.

@ ext-jason.rudd@nokia.com
I understand your argument about ifconfig cutting power of the wifi radio,
nonetheless empirically it seems to me that battery drain is still a little
faster than when the module is unloaded and the device is a little warmer.
This obviously could be just my biased perception of things as I've found
no way to measure it yet.

(In reply to comment #137)
> I've uploaded latest version of wifi switcher control panel applet if somebody
> prefers to use it rather than the proposed _working_ fix.
> 
Thank You Tito.

I still use your tool since I couldn't get the proposed fix to work.

I create a file named "zz_static_ip_if_down" and put it in
/etc/network/if-post-down.d/.

Then chmod +x zz_static_ip_if_down.

Then rebooted but fast drainage still there.
Could someone please post a more accurate (noob-proof) method of putting this
to work?

Thanks

Look's like "temporary" solution from Markus helps in case of regular WiFi too
(not adhoc or static). I think the reason is in often scanning WiFi.

BTW, WiFi switch off actually just prevents scanning wiFi then you roaming
around and saves the battery. It can be a reason why farmatito feels the
additional improvement.

(In reply to comment #139)
> BTW, WiFi switch off actually just prevents scanning wiFi then you roaming
> around and saves the battery. It can be a reason why farmatito feels the
> additional improvement.

I must admit, combining the two seems best to me: ifdown automatically when
disconnected and switch off wireless completely if desired/wanted

Franky

(In reply to comment #129)
> if [ "$ICD_CONNECTION_TYPE" = WLAN_INFRA || "$ICD_CONNECTION_TYPE" = WLAN_ADHOC
> ]; then
>        ifconfig $IFACE down
> fi

This doesn't work. I get a "missing ]" error when testing
  MODE=stop ./zz_static_ip_if_down

I think that ash is too primitive to understand the non-standard || in test.

Comment 143 Eero Tamminen 2010-01-22 11:35:59 UTC

(In reply to comment #141)
> (In reply to comment #129)
> > if [ "$ICD_CONNECTION_TYPE" = WLAN_INFRA || "$ICD_CONNECTION_TYPE" = WLAN_ADHOC
> > ]; then
> >        ifconfig $IFACE down
> > fi
> 
> This doesn't work. I get a "missing ]" error when testing
>   MODE=stop ./zz_static_ip_if_down

The "]; then" needs to be on the same line with the rest of the test (or you
need to tell shell with "\" as the last character on line that the line
continues to next line).


(In reply to comment #142)
> I think that ash is too primitive to understand the non-standard || in test.

It's a POSIX shell.  Of course it has it.

(In reply to comment #142)
> I think that ash is too primitive to understand the non-standard || in test.

So is the GNU coreutils /usr/bin/[, try the POSIXly-correct -o (or -a for the
script in comment 119) instead :-)

Comment 145 Eero Tamminen 2010-01-22 11:54:22 UTC

(In reply to comment #143)
> The "]; then" needs to be on the same line with the rest of the test (or you
> need to tell shell with "\" as the last character on line that the line
> continues to next line).

Sorry, misread that line.  "||" can be used, but then it needs to be like this:
[ test1 ] || [ test2 ], "||" cannot be inside brackets.  And as Lucas stated,
-a & -o can be used inside the brackets.

Can the people on this bug indicate which on-line (IM) accounts are active and
logged-in when they see this bug?

It seems clear to me that setting my availability "offline" seriously improves
battery performance.  Then I looked at each of my individual account types and
noticed that only when MSN was "available" was the battery drained quickly. 
Then I switched MSN plugins from Haze to Pecan.  This alone seems to just about
double my battery life.  There is some noise on the net that the Pecan
implementation is more "efficient".  Perhaps it is sending less traffic and
waking up the CPU less often?

My tests are not quantitative.  Can anyone else confirm/refute my observations?

Can the people on this bug indicate which on-line (IM) accounts are active and
logged-in when they see this bug?

It seems clear to me that setting my availability "offline" seriously improves
battery performance.  Then I looked at each of my individual account types and
noticed that only when MSN was "available" was the battery drained quickly. 
Then I switched MSN plugins from Haze to Pecan.  This alone seems to just about
double my battery life.  There is some noise on the net that the Pecan
implementation is more "efficient".  Perhaps it is sending less traffic and
waking up the CPU less often?

My tests are not quantitative.  Can anyone else confirm/refute my observations?

Can the people on this bug indicate which on-line (IM) accounts are active and
logged-in when they see this bug?

It seems clear to me that setting my availability "offline" seriously improves
battery performance.  Then I looked at each of my individual account types and
noticed that only when MSN was "available" was the battery drained quickly. 
Then I switched MSN plugins from Haze to Pecan.  This alone seems to just about
double my battery life.  There is some noise on the net that the Pecan
implementation is more "efficient".  Perhaps it is sending less traffic and
waking up the CPU less often?

My tests are not quantitative.  Can anyone else confirm/refute my observations?

Can the people on this bug indicate which on-line (IM) accounts are active and
logged-in when they see this bug?

It seems clear to me that setting my availability "offline" seriously improves
battery performance.  Then I looked at each of my individual account types and
noticed that only when MSN was "available" was the battery drained quickly. 
Then I switched MSN plugins from Haze to Pecan.  This alone seems to just about
double my battery life.  There is some noise on the net that the Pecan
implementation is more "efficient".  Perhaps it is sending less traffic and
waking up the CPU less often?

My tests are not quantitative.  Can anyone else confirm/refute my observations?

Can the people on this bug indicate which on-line (IM) accounts are active and
logged-in when they see this bug?

It seems clear to me that setting my availability "offline" seriously improves
battery performance.  Then I looked at each of my individual account types and
noticed that only when MSN was "available" was the battery drained quickly. 
Then I switched MSN plugins from Haze to Pecan.  This alone seems to just about
double my battery life.  There is some noise on the net that the Pecan
implementation is more "efficient".  Perhaps it is sending less traffic and
waking up the CPU less often?

My tests are not quantitative.  Can anyone else confirm/refute my observations?

Can the people on this bug indicate which on-line (IM) accounts are active and
logged-in when they see this bug?

It seems clear to me that setting my availability "offline" seriously improves
battery performance.  Then I looked at each of my individual account types and
noticed that only when MSN was "available" was the battery drained quickly. 
Then I switched MSN plugins from Haze to Pecan.  This alone seems to just about
double my battery life.  There is some noise on the net that the Pecan
implementation is more "efficient".  Perhaps it is sending less traffic and
waking up the CPU less often?

My tests are not quantitative.  Can anyone else confirm/refute my observations?

Can the people on this bug indicate which on-line (IM) accounts are active and
logged-in when they see this bug?

It seems clear to me that setting my availability "offline" seriously improves
battery performance.  Then I looked at each of my individual account types and
noticed that only when MSN was "available" was the battery drained quickly. 
Then I switched MSN plugins from Haze to Pecan.  This alone seems to just about
double my battery life.  There is some noise on the net that the Pecan
implementation is more "efficient".  Perhaps it is sending less traffic and
waking up the CPU less often?

My tests are not quantitative.  Can anyone else confirm/refute my observations?

Comment 153 ext-jason.rudd@nokia.com 2010-01-22 13:35:28 UTC

RE: MSN Please refer to 8000 - this bug stracks the static IP only

Comment 154 ext-jason.rudd@nokia.com 2010-01-22 13:36:49 UTC

Apologies MSN problem is tracked in 8004

(In reply to comment #131)
> The change of the script from && too || triggered the drainage bug again.
> I'am no developer but the script with && works for me.

Because [ test1 || test2 ] is incorrect thus always fails. It should be:
[ test1 ] || [ test2 ]. Similarly, [ test1 && test2 ] always fails, but in this
case, the ifconfig is always executed: the drainage bug no longer appears, but
with a possible side effect: under some cases (which ones?), the interface may
be brought down while it should remain up.

(In reply to comment #145)
> Sorry, misread that line.  "||" can be used, but then it needs to be like this:
> [ test1 ] || [ test2 ], "||" cannot be inside brackets.  And as Lucas stated,
> -a & -o can be used inside the brackets.

[ test1 ] || [ test2 ] is safer. -a and -o are underspecified (in corner cases)
and declared as obsolescent in POSIX.

Can the people on this bug indicate which on-line (IM) accounts are active and
logged-in when they see this bug?

It seems clear to me that setting my availability "offline" seriously improves
battery performance.  Then I looked at each of my individual account types and
noticed that only when MSN was "available" was the battery drained quickly. 
Then I switched MSN plugins from Haze to Pecan.  This alone seems to just about
double my battery life.  There is some noise on the net that the Pecan
implementation is more "efficient".  Perhaps it is sending less traffic and
waking up the CPU less often?

My tests are not quantitative.  Can anyone else confirm/refute my observations?

Can the people on this bug indicate which on-line (IM) accounts are active and
logged-in when they see this bug?

It seems clear to me that setting my availability offline seriously improves
battery performance.  Then I looked at each of my individual account types and
noticed that only when MSN was available was the battery drained quickly. 
Then I switched MSN plugins from Haze to Pecan.  This alone seems to just about
double my battery life.  There is some noise on the net that the Pecan
implementation is more efficient.  Perhaps it is sending less traffic and
waking up the CPU less often?

My tests are not quantitative.  Can anyone else confirm/refute my observations?

Can the people on this bug indicate which on-line (IM) accounts are active and
logged-in when they see this bug?

It seems clear to me that setting my availability offline seriously improves
battery performance.  Then I looked at each of my individual account types and
noticed that only when MSN was available was the battery drained quickly. 
Then I switched MSN plugins from Haze to Pecan.  This alone seems to just about
double my battery life.  There is some noise on the net that the Pecan
implementation is more efficient.  Perhaps it is sending less traffic and
waking up the CPU less often?

test

test

test

Sorry for the repeated comments, I'm triggering bug #7854 when I post, trying
to figure out why...

I had an experience very similar to comment #27 twice today - noticed that my
n900 was super warm, and battery life was dropping like mad.   both times I ran
top, and noticed that /usr/sbin/wlancond was pulling something like 99.7% of
the cpu continuously.

I rebooted, and the phone started to cool down, and the battery life got better
afterwards.   I was not trying to get on wifi recently before either occurance.

I've only had my n900 for about a week, and didn't notice the behaviour before
- the only new thing today is that I'm on a business trip from montreal to
Boston, and so am now using data roaming.  The first time I noticed the n900
being super warm was maybe 1.5 hours after crossing the border.  don't know if
that is related.

Comment 165 Andre Klapper 2010-01-28 01:49:16 UTC

This has been fixed in package
icd2 0.87+fremantle6.1+0m5 /
icd2 0.87+fremantle8+0m5 and libicd-network-ipv4 0.24+0m5
which is part of the internal build version
2009.51-5
(Note: 2009/2010 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


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/

Will have the workaround script in /etc/network/if-post-down.d/ to be removed
before the upgrade (or after it)?

After all, it seems like my initial problem wasn't related to this bug: I've
always used DHCP. Currently with the 2.2009.51-1 firmware I get easily over 16
hours of battery life with WLAN+skype on for almost all the time (idle), an
hour of listening music + few hours of random surfing/calling/sending text
messages and so on.

Finding out what eats the battery can be hard, since people have different
software installed and so on, so to help debuging the future bugs relating to
battery life what are the best additional information that one should attach to
the bug report? Output from top, powertop, 'ps aux', dmesg... + something else?
Someone could make a help page somewhere where these things are listed, if
there isn't one already?

(In reply to comment #166)
> Will have the workaround script in /etc/network/if-post-down.d/ to be removed
> before the upgrade (or after it)?
> 

Unless your workaround script happens to have the same name as what'll be in
the upgrade it won't be critical - you may remove it before or after the
upgrade. In the latter case there will be two scripts trying to do the same
thing, but for one of them the test will indicate that wlan is already shut
down and it'll do nothing.

OK. I was wondering how the bug was fixed. A script in
/etc/network/if-post-down.d was more like a workaround/hack than a real fix,
since it seems strange to shut down an interface in a post-down hook (meaning
that the interface should already be down).

(In reply to comment #169)
> OK. I was wondering how the bug was fixed. A script in
> /etc/network/if-post-down.d was more like a workaround/hack than a real fix,
> since it seems strange to shut down an interface in a post-down hook (meaning
> that the interface should already be down).

Indeed, and for some (most?) users the interface does go down as intended, even
with 1.0 or 1.1. In any case the workaround script seems safe and should not be
able to do any harm - thus its removal can be done when convenient and isn't
critical. (I don't think it has been described in this thread how the "real"
fix is to be implemented in a future upgrade).

FYI 

wifi-switcher is now in Extras-Testing for those wishing to install the
temporally fix through App Manager rather than downloading the .deb and use
dpkg

Link -
http://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/wifi-switcher/0.0.5/

Please vote as well!

Comment 172 Andre Klapper 2010-01-29 20:55:28 UTC

Venomrush, please mention the danger for normal users.

(In reply to comment #171)
> wifi-switcher is now in Extras-Testing for those wishing to install the
> temporally fix through App Manager rather than downloading the .deb and use
> dpkg

*** The software hosted in extras-testing is not ready for normal users! ***
Venomrush, please **ALWAYS** mention the risks when sending normal users out of
the safe Extras area! See http://talk.maemo.org/showthread.php?p=343619 .

> Please vote as well!

Note that this Voting is completely different from Voting for a bug report
here.
See http://wiki.maemo.org/Extras-testing#Quality_Assurance_criteria : "Don't
vote for an application before having a good understanding of its quality."
Simply "Oh yeah, I want this!" clicks are NOT welcome and undermine the Quality
Assurance system that we have in the maemo.org community.

Comment 173 Andre Klapper 2010-02-16 14:06:33 UTC

The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 3.2010.02-8 (also called "PR1.1.1"
sometimes).
Please leave a comment if the problem is not fixed for you in this update
version.

After the upgrade, I got a script named "zz_static_ip_if_down.dpkg-dist",
probably because I already had a script "zz_static_ip_if_down".

Now it seems that the zz_static_ip_if_down.dpkg-dist script is incorrect as it
contains a test of the form:
  [ test1 && test2 ]
which is not a valid POSIX construct. See comment #155.

Comment 175 Markus Silvan 2010-02-17 09:07:15 UTC

(In reply to comment #174)
> After the upgrade, I got a script named "zz_static_ip_if_down.dpkg-dist",
> probably because I already had a script "zz_static_ip_if_down".

Yes, that's why you got it. Just remove it.

> Now it seems that the zz_static_ip_if_down.dpkg-dist script is incorrect as it
> contains a test of the form:
>   [ test1 && test2 ]
> which is not a valid POSIX construct. See comment #155.
> 

That is fixed in some upcoming update. Currently it will just cause an extra
ifconfig down call for interfaces that are already down at this point so it
shouldn't have any functional difference.

(In reply to comment #173)
> The problem reported here should be fixed in the update released today for
> public: The Maemo5 update version 3.2010.02-8 (also called "PR1.1.1"
> sometimes).
> Please leave a comment if the problem is not fixed for you in this update
> version.
> 

I applied the update yesterday - 'about product' shows 'Version:
3.2010.02-8.002"

however, this morning I noticed that my phone was very warm, and my battery was
dropping very quickly.   I ran top in the X terminal and noticed that
/usr/sbin/wlancond was continuously grabbing about 95% of my cpu.   

This is a behaviour I've seen quite a lot since I got my n900 a few weeks back,
and I *thought* it was this issue.    Is it something different?   Should I
open a new bug, or is there an issue for it already?

It is something different. For the bug here, no processes consume CPU time.

(In reply to comment #176)
> however, this morning I noticed that my phone was very warm, and my battery was
> dropping very quickly.   I ran top in the X terminal and noticed that
> /usr/sbin/wlancond was continuously grabbing about 95% of my cpu.   

This sounds like a different (userland) issue, please file a separate report
for it.  See
<http://wiki.maemo.org/Bugs:Stock_answers#Software_hangs_with_100.25_CPU> for
the kind of information that would be useful there.

In the interests of avoiding duplicate reports: bug 9153 now deals with the
wlancond CPU case.

I find that 3.2010.02-8 doesn't really fix the problem, 50% of the time if the
wifi is on but not connected to an AP, the battery drains very quickly. Using
WifiSwitcher resolves it.

Sometimes it is so bad that, although on the charger, it isn't even charging
much. The charge animation/led are shown, so it must be the wifi drain causing
this.

Should I re-open this bug?

(In reply to comment #180)
> I find that 3.2010.02-8 doesn't really fix the problem, 50% of the time if the
> wifi is on but not connected to an AP, the battery drains very quickly.

What do you mean by "the wifi is on"? If you mean that you configured your
device to constantly try to connect to an AP, then battery drain may be normal.

This bug is about a disconnection that occurred (but it was not handled
correctly), and the N900 remains disconnected.

I mean the wifi is allowed to scan for networks (does so every 15 minutes) as
opposed to disabled by wifi-switcher.

And btw, this bugreport was ACTUALLY about an issue of battery drain when using
3G, not wifi. See the original report. Then somebody hijacked the report. So go
easy on claiming my post is not related :P

Either way, I see no real difference with the new release, so the bug is not
fixed

(In reply to comment #182)
> I mean the wifi is allowed to scan for networks (does so every 15 minutes) as
> opposed to disabled by wifi-switcher.

But what if you disable scanning?

> And btw, this bugreport was ACTUALLY about an issue of battery drain when using
> 3G, not wifi. See the original report. Then somebody hijacked the report.

The report wasn't hijacked: the summary was "Battery Dies Under 6 Hours with
Very Moderate Use" and the steps to reproduce the problem were just an example
(the battery drain problem was also known to exist on the N810 after using
wifi).

> So go easy on claiming my post is not related :P

With the additional information, it could be related: check with the
/sbin/ifconfig command (from the terminal) while you're not connected (and
while the N900 isn't scanning, e.g. try every 2 minutes to be sure). If you see
wlan0 always listed as UP, then this can be regarded as the same bug. The
problem was "fixed" by a workaround that can work only if the connection
succeeded. This means that if the bug also occurs due to unsuccessful scanning
(i.e. wlan0 remains UP), then the workaround won't work.

A new filed bug contributes also to battery drainage, wifi related. See 'Wifi
is still transmitting when not connected, even in offline mode' - Bug 9146

Comment 185 Andre Klapper 2010-03-11 16:02:50 UTC

*** Bug 3992 has been marked as a duplicate of this bug. ***

There's still a similar problem with wlan0 remaining up, but apparently due to
interrupted scanning. I've reported bug 9628. It may be related to bug 9146,
mentioned in comment #184.

Re-Open bug...not solved ..it's clear that the problem still there

(In reply to comment #187)
> Re-Open bug...not solved ..it's clear that the problem still there

This bug in on a particular bug (related to static IP -- perhaps the summary is
not clear enough), which has been fixed. Perhaps you're seeing another bug. See
bug 9146 and bug 9628 for instance. But it may be something else.

I noticed that if I have GPS enabled in Settings->GPS Positioning (I'm sorry if
it isn't the right path, but my N900 isn't in english), but WITHOUT any GPS
program open, battery goes down very quickly, if it is disabled there's not
strange power consumption!

Generally after using a gps application, it seems that GPS remain ON. It seems
also that if I have GPS enabled, but I rebooted N900 after closing a GPS app
the problem is not present.