maemo.org - Talk - Battery Dies too Quickly

maemo.org - Talk (https://talk.maemo.org/index.php)

- Maemo 5 / Fremantle (https://talk.maemo.org/forumdisplay.php?f=40)

- - Battery Dies too Quickly (https://talk.maemo.org/showthread.php?t=71843)

Re: Battery Dies too Quickly

Can we try to keep the chafe to a minimum please? Many of the programs people are suggesting for removal have NO background running components (with the possible exception of the battery monitoring programs).

Removing things like installers, or tutorials is fine for trying to recover space, but they'll have 0 impact on battery use. And CLI programs like espeak, or manually triggered scripts like flashlight? What does that have to do with battery use? Nothing. I think the author would have noted if the device were babbling constantly or emitting a bright light.

The more likely issue is there something happening with hardware being triggered, based on the high IRQ levels and dss usage. It may be a bad wifi or APN entry, or a bluetooth device asking for ID every few minutes. Or, it could be a bad chip or micro switch, maybe the device is close to a magnetic source (like a pouch magnet, or a motor) that's triggering the micro switches? Running the hardware tester app may be a good thing to try as well if you're trying to avoid a reflash.

There's enough going on here that I think your real solution is going to be to reflash to PR1.3 to eliminate possible software causes. Espeak is not a default component, nor are at lot of the packages listed. There's a lot of stuff installed, and if you didn't install it then someone else did, maybe before you got the device.

If you just got it, and didn't put all this on it, it will be a *lot* easier to backup your data, reflash, and just put the stuff you want on, vs trying to undo all the changes someone else did. Also, if your issue is settings or hardware based (which I suspect it is based on the log), a reflash will help pin point that quickly, vs lots of trial and error.

Quote:

Originally Posted by HellFlyer (Post 982750)

Remove those things
tutorial-home-applet
facebook-installer 1.0-4.1.1+0m5 user/other 88
facebook-services 0.5.5 user/hidden 52
foreca-installer 1.0.1.1+0m5 user/other 88
amazon-installer 1.0.1.1+0m5 user/other 96
battery-eye 0.7.7-1 user/utilities 196
batterygraph 0.3.2 user/utilities 356

Quote:

Originally Posted by Switch_ (Post 982877)

Okay, remove as follows:
amazon-installer
appdownloader
autodisconnect
battery-eye
buddy
espeak
maxcpu
tutorial-home-applet

Quote:

Originally Posted by vi_ (Post 982882)

oh and get rid of that stupid flashlight program too, it is a known ballache.

Re: Battery Dies too Quickly

@woody14619

i OC to 900mhz

Re: Battery Dies too Quickly

IMO the battery of n900 is to weak to power the phone to do all the task nokia 5800 XM same battery with n900

Re: Battery Dies too Quickly

Quote:

Originally Posted by woody14619 (Post 983183)

Okay, obviously someone who knows what they are talking about!

Quote:

Originally Posted by woody14619 (Post 983183)

There's enough going on here that I think your real solution is going to be to reflash to PR1.3 to eliminate possible software causes. .

Oh. Erm. Hang on one second.

Thats a direct contradiction to what you said above. Chafe? Reflash? Chafe = Reflash same as Reflash = Chafe.

We suggest that he removes things that are known to potentially cause issues - along with other apps running dbus daemons and the like and you, in contravention, suggest that the OP's only recourse is a complete reflash?

What a ballache.

I try to suggest flashing as a last resort, as these issues can be fixed in a multitude of ways that do not resort to a complete reflash and rebuild of the OS.

Either help, through analysis of posted outputs, or GTFO. Flash is last resort when everything else has failed.

Re: Battery Dies too Quickly

Quote:

Originally Posted by maxppc (Post 983150)

Here is my Powertop output after fresh start as explained before

Code:

Powertop 1.13.3

Sleeping for 11 seconds before sampling

Collecting data for 30 seconds

Sample interval was 00m 30s 32684us



C#      | Ratio  | Avg/dura | Frequency | Ratio

--------+--------+----------+-----------+--------+

     C0 |   0.7% |          |   600 MHz |   3.1% |

     C1 |   0.0% |    0.3ms |   550 MHz |   0.0% |

     C2 |   2.4% |    4.4ms |   500 MHz |   4.3% |

     C3 |   4.4% |   89.0ms |   250 MHz |  92.7% |

     C4 |  92.5% | 1389.0ms | 



IRQ#    | Activity   | Type           | Name

--------+------------+----------------+---------------------------

     56 |        365 |           INTC | i2c_omap

     57 |        260 |           INTC | i2c_omap

     11 |        142 |           INTC | prcm

     86 |         89 |           INTC | mmc1

     37 |         56 |           INTC | gp

     12 |         19 |           INTC | DMA

     61 |          5 |           INTC | i2c_omap



PID#    | Activity   | Name           | Function Entry (Expire)

--------+------------+----------------+---------------------------

      0 |         23 |  <kernel core> | tick_nohz_restart_sched_tick (tick_sched_timer)

     37 |         16D|            awk | cpufreq_governor_dbs (delayed_work_timer_fn)

    704 |         10 |      bme_RX-51 | sys_timer_settime (posix_timer_fn)

      0 |          9 |  <kernel core> | hrtimer_start (tick_sched_timer)

    704 |          6 |      bme_RX-51 | sys_timer_settime (posix_timer_fn)

    704 |          6 |      bme_RX-51 | schedule_timeout (process_timeout)

    615 |          4 |          mmcqd | queue_delayed_work (delayed_work_timer_fn)

      1 |          3D|  <kernel core> | queue_delayed_work (delayed_work_timer_fn)

    771 |          2 |            mce | queue_delayed_work (delayed_work_timer_fn)

    704 |          2 |      bme_RX-51 | do_nanosleep (hrtimer_wakeup)

    675 |          2 |           dsme | do_nanosleep (hrtimer_wakeup)

    675 |          2 |           dsme | __enqueue_rt_entity (sched_rt_period_timer)

    818 |          1 |     pulseaudio | queue_delayed_work (delayed_work_timer_fn)

    748 |          1 |     pulseaudio | schedule_hrtimeout_range (hrtimer_wakeup)

     29 |          1 |          mount | setup_wb_timer (wb_timer_fn)

     14 |          1 |        pdflush | journal_get_write_access (commit_timeout)

    884 |          1 | hald-addon-bme | schedule_hrtimeout_range (hrtimer_wakeup)

   1098 |          1 |          iphbd | schedule_hrtimeout_range (hrtimer_wakeup)

   1602 |          1 |       powertop | do_nanosleep (hrtimer_wakeup)



Power domain activity breakdown

Domain  | % of time spent in states

--------+---------+---------+---------+---------+----------

usbhost |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)

    sgx |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)

    per |OFF:  94%|RET:   4%|INA:   0%| ON:   0%| now:(ON)

    dss |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)

    cam |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)

   core |OFF:  91%|RET:   3%|INA:   0%| ON:   5%| now:(ON)

   neon |OFF:  92%|RET:   4%|INA:   2%| ON:   0%| now:(ON)

    mpu |OFF:  92%|RET:   4%|INA:   2%| ON:   0%| now:(ON)

   iva2 |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)



Clock activity breakdown at end of period

Domain  | Active clocks

--------+---------------+---------------+------------------

   core |          SDRC | HSOTGUSB_IDLE |      OMAPCTRL 

        |     MAILBOXES |

   wkup |          GPT1 |       32KSYNC |         GPIO1 

        |          WDT1 |

  ckgen |          CORE |          PERI |           96M 

        |           48M |           12M |           54M 

        |      EMU_CORE |

    per |         GPIO2 |         GPIO3 |         GPIO4 

        |         GPIO5 |         GPIO6 |



Total wakeups  1028,  34.3/s | IRQ  936,  31.2/s | Timers   92,   3.1/s

HW wakeups      142,   4.7/s |     Real gp_timers expired   56,   1.9/s

Is here anything I should care about?

Thanks

No, this is more or less perfect.

Re: Battery Dies too Quickly

I'm not smart enough to get my head around all the event logs posted here, but my battery was being drained by a faulty wireless router last year. I replaced the router and battery life returned to normal.

This got me thinking about the impact of wifi on battery life. After monitoring my data use for a few months, I realised that I was unlikely to exceed my 1 gig allowance anyway so I now keep wifi turned off except for specific circumstances (need more speed, big download, etc.). Running two radios instead of just one obviously uses more power. Lately, I get about two days from my battery.

Re: Battery Dies too Quickly

Quote:

Originally Posted by Switch_ (Post 983453)

Thats a direct contradiction to what you said above. Chafe? Reflash? Chafe = Reflash same as Reflash = Chafe.

The OP said he JUST got his device a month ago in his top post. It's not clear if it's a second hand device or not, but the fact that there are multiple programs installed that he apparently doesn't recognize would indicate it's probably a second-hand device. Given that, I simply stated it would be far easier to backup what little content he's personally put on it in the past month, and re-flash it, rather than try to diagnose and undo what someone else did to it before he owned it! That's not chafe, it's common sense.

As I already noted, there's a lot of IRQ and dss activity going on, which indicate a bad setting or possibly faulty hardware. (Kudos to Andrew_b: Yes, it could be an external component, like bad wifi point, or a bluetooth device like I mentioned earlier.) I put in the post above alternate things to check for or try if he's trying to avoid doing a reflash.

At no point did I say "the ops o(sic) recourse is a complete reflash". Please don't put words in my mouth, saying I said something when clearly I said no such thing. (That's called lying in my country...) Sad that you find the need to be-little my comments to cover for your suggesting useless "fixes" like telling someone that uninstalling a tutorial video or a non-active app installer will help with their battery usage.

Re: Battery Dies too Quickly

Quote:

Originally Posted by woody14619 (Post 983799)

I agree that removing applications that are not actively running won't do much to help the battery drain issues.

This phone is brand "spanking" new :) Also, I don't know if it makes much of a difference but it appears to have the latest firmware running on it.

I'm not sure how to check for faulty hardware. But here's my output of powertop:

Code:

Powertop 1.13.3

Sleeping for 11 seconds before sampling

Collecting data for 30 seconds

Sample interval was 00m 30s 16449us



C#      | Ratio  | Avg/dura | Frequency | Ratio

--------+--------+----------+-----------+--------+

     C0 |   1.6% |          |  1150 MHz |   nan% |

     C1 |   0.0% |    0.2ms | 

     C2 |   0.7% |    3.2ms | 

     C3 |  23.8% |   35.7ms | 

     C4 |  73.9% |   96.9ms | 



IRQ#    | Activity   | Type           | Name

--------+------------+----------------+---------------------------

     12 |       2098 |           INTC | DMA

     11 |        347 |           INTC | prcm

    202 |        297 |           GPIO | wl1251

     56 |        125 |           INTC | i2c_omap

     37 |         70 |           INTC | gp

     57 |         58 |           INTC | i2c_omap



PID#    | Activity   | Name           | Function Entry (Expire)

--------+------------+----------------+---------------------------

     38 |         40D|            awk | cpufreq_governor_dbs (delayed_work_timer_fn)

      0 |         38 |  <kernel core> | tick_nohz_restart_sched_tick (tick_sched_timer)

    705 |         14 |      bme_RX-51 | sys_timer_settime (posix_timer_fn)

      0 |         11 |  <kernel core> | hrtimer_start (tick_sched_timer)

    705 |          6 |      bme_RX-51 | schedule_timeout (process_timeout)

    784 |          4 |            mce | tsc2005_start_scan (tsc2005_esd_timer_handler)

      0 |          3 |  <kernel core> | queue_delayed_work (delayed_work_timer_fn)

     10 |          3 |    omap2_mcspi | neigh_add_timer (neigh_timer_handler)

    705 |          3 |      bme_RX-51 | sys_timer_settime (posix_timer_fn)

    701 |          2D|<kernel module> | queue_delayed_work (delayed_work_timer_fn)

    667 |          2 |           dsme | do_nanosleep (hrtimer_wakeup)

    667 |          2 |           dsme | __enqueue_rt_entity (sched_rt_period_timer)

    705 |          2 |      bme_RX-51 | do_nanosleep (hrtimer_wakeup)

   1344 |          1 |           eapd | fib6_force_start_gc (fib6_gc_timer_cb)

      1 |          1D|  <kernel core> | queue_delayed_work (delayed_work_timer_fn)

   1826 |          1 |       powertop | do_nanosleep (hrtimer_wakeup)



Power domain activity breakdown

Domain  | % of time spent in states

--------+---------+---------+---------+---------+----------

usbhost |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)

    sgx |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)

    per |OFF:  97%|RET:   0%|INA:   0%| ON:   1%| now:(ON)

    dss |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)

    cam |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)

   core |OFF:  73%|RET:  23%|INA:   0%| ON:   1%| now:(ON)

   neon |OFF:  73%|RET:  23%|INA:   0%| ON:   1%| now:(ON)

    mpu |OFF:  73%|RET:  23%|INA:   0%| ON:   1%| now:(ON)

   iva2 |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)



Clock activity breakdown at end of period

Domain  | Active clocks

--------+---------------+---------------+------------------

   core |          SDRC | HSOTGUSB_IDLE |      OMAPCTRL 

        |     MAILBOXES |

   wkup |          GPT1 |       32KSYNC |         GPIO1 

        |

  ckgen |          CORE |          PERI |           96M 

        |           48M |           12M |           54M 

        |      EMU_CORE |

    per |         GPIO2 |         GPIO3 |         GPIO4 

        |         GPIO5 |         GPIO6 |



Total wakeups  3128, 104.3/s | IRQ 2995,  99.8/s | Timers  133,   4.4/s

HW wakeups       91,   3.0/s |     Real gp_timers expired   70,   2.3/s

Sorry for missing out on a day of this post. It looks like it stayed pretty active haha. Thanks guys :)

Re: Battery Dies too Quickly

Quote:

Originally Posted by kurtis (Post 983820)

I'm not sure how to check for faulty hardware. But here's my output of powertop:

It's no longer showing any of the same behavior. Dss is totally dead, and the IRQ counts look semi-sane (except for the wifi... that looks a little high still). Is it still exhibiting the drain problem?

It may in fact be an external cause, like a bad wifi router or bluetooth device pegging it. I once had a stale password in for a wifi router, and with the auto-connect attempts every 5 minutes or so it ate through half my battery in about 4 hours. Maybe something similar is happening?

Re: Battery Dies too Quickly

DSS is typically active whenever the screen is on. If the first measurement wasn't done with screen off, you'd get bad results.