maemo.org Bugzilla – Bug 6615
Battery Dies Under 6 Hours with Very Moderate Use (Static IP?)
Last modified: 2010-04-04 13:44:27 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: Nokia N900 Maemo 5 1.2009.42-11.002 EXACT STEPS LEADING TO PROBLEM: Wifi/GPS/FM Transmitter/Bluetooth all OFF Skype/IM/Email NOT EVEN SETUP AT ALL NO 3rd Party Apps installed Battery has been charged properly and gone through several cycles Got a replacement unit already and same exact issue Make 2 phone calls, 20 texts, surf the internet for 2 hours over 3G and phone dies (all within 6 hours). EXPECTED OUTCOME: Battery last 12 hours or more with similar use (or from waking up to going to bed ideally) ACTUAL OUTCOME: Battery dies before reaching 6 hours of up time. REPRODUCIBILITY: Always EXTRA SOFTWARE INSTALLED: None OTHER COMMENTS: ALOT of people seem to have the same issue, everyone is getting extremely frustrated. Especially when we hear that others have 20 hours or more of battery life with similar usage. Is this going to be fixed in the new OTA? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.33 Safari/532.0
I have this same problem, but a bit more of use. I use skype>alk, 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
(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.
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.
(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.
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.
(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.
> 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/*").
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.
(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).
(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).
(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.
(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.
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
(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 !
************************************************************************ 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.
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.
(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 :)
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.
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
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
> 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 !?!
(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.
"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.
(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 :-)
(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?
RE: MSN Please refer to 8000 - this bug stracks the static IP only
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?
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.
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!
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.
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.
(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
*** 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.