Active Topics
-
[HOWTO] Comprehensive Firmware Flashing Guide for N9 (1,580)
to Nokia N9 / N950 by aspergerguy - 2 hrs, 25 mins ago -
Nokia N9-00 Prototype Build S1.12 (RM-680 codename "Dali") (250)
to Nokia N9 / N950 by en0s - 2 days, 22 hrs ago -
[Announce] Maebble - Pebble support for Maemo (118)
to Applications by glo-worm - 3 days, 11 hrs ago -
Possible to flash Leste to eMMC? (6)
to Maemo 7 / Leste by Eri - 4 days, 1 hr ago - more...
|
2011-04-06
, 22:42
|
|
Posts: 42 |
Thanked: 3 times |
Joined on Aug 2010
@ philippines
|
#32
|
@woody14619
i OC to 900mhz
i OC to 900mhz
|
|
2011-04-06
, 22:50
|
|
Posts: 42 |
Thanked: 3 times |
Joined on Aug 2010
@ philippines
|
#33
|
IMO the battery of n900 is to weak to power the phone to do all the task nokia 5800 XM same battery with n900
 |
|
2011-04-07
, 07:40
|
|
Posts: 601 |
Thanked: 549 times |
Joined on Mar 2010
@ Redditch, UK
|
#34
|
Originally Posted by woody14619
Okay, obviously someone who knows what they are talking about!
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).
Originally Posted by woody14619
Oh. Erm. Hang on one second.
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. .
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.
Last edited by Switch_; 2011-04-07 at 07:48.
|
|
2011-04-07
, 08:00
|
|
Posts: 1,680 |
Thanked: 3,685 times |
Joined on Jan 2011
|
#35
|
Originally Posted by maxppc
No, this is more or less perfect.
Here is my Powertop output after fresh start as explained before
Is here anything I should care about?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
Thanks
__________________
N900: One of God's own prototypes. A high-powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die.
| The Following User Says Thank You to vi_ For This Useful Post: | ||
|
|
2011-04-07
, 08:24
|
|
Posts: 123 |
Thanked: 122 times |
Joined on Feb 2010
|
#36
|
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.
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.
 |
|
2011-04-07
, 18:05
|
|
Posts: 1,455 |
Thanked: 3,309 times |
Joined on Dec 2009
@ Rochester, NY
|
#37
|
Originally Posted by Switch_
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.
|
|
2011-04-07
, 18:54
|
|
Posts: 26 |
Thanked: 7 times |
Joined on Mar 2011
|
#38
|
Originally Posted by woody14619
I agree that removing applications that are not actively running won't do much to help the battery drain issues.
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.
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
|
|
2011-04-08
, 22:21
|
|
Posts: 1,455 |
Thanked: 3,309 times |
Joined on Dec 2009
@ Rochester, NY
|
#39
|
Originally Posted by kurtis
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?
I'm not sure how to check for faulty hardware. But here's my output of powertop:
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?
|
|
2011-04-09
, 10:20
|
|
Posts: 1,258 |
Thanked: 672 times |
Joined on Mar 2009
|
#40
|
DSS is typically active whenever the screen is on. If the first measurement wasn't done with screen off, you'd get bad results.
 |
| Tags |
| bada rox, battery, battery drain, uselessappz |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 18:48.
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.