Active Topics

 


Reply
Thread Tools
peterleinchen's Avatar
Posts: 4,118 | Thanked: 8,901 times | Joined on Aug 2010 @ Ruhrgebiet, Germany
#21
Okay, sorry.

But with that huge amount of CPU load you should see the process with top/htop, or?
__________________
SIM-Switcher, automated SIM switching with a Double (Dual) SIM adapter
--
Thank you all for voting me into the Community Council 2014-2016!

Please consider your membership / supporting Maemo e.V. and help to spread this by following/copying this link to your TMO signature:
[MC eV] Maemo Community eV membership application, http://talk.maemo.org/showthread.php?t=94257

editsignature, http://talk.maemo.org/profile.php?do=editsignature
 

The Following 2 Users Say Thank You to peterleinchen For This Useful Post:
Posts: 25 | Thanked: 19 times | Joined on Apr 2014
#22
CPU usage on top hovers around the 2~6% mark most of the time. Xorg and browserd are among processes that are most active. Afraid I'm quoting this from crude visual inspection. Is there a way to log the top output?

As Estel said, the problem appears to be that the device just doesn't want to sleep. Here's a wild shot - could it be that the sensor/trigger behind the lock switch was somehow damaged during the time that the switch was broken and exposed?
 
peterleinchen's Avatar
Posts: 4,118 | Thanked: 8,901 times | Joined on Aug 2010 @ Ruhrgebiet, Germany
#23
Originally Posted by codelad View Post
Is there a way to log the top output?
Sure: top --help
or:
top -b -n 5 -d 2
will call top five times with a delay of 2 seconds. You may do whatever you want with the output ...
__________________
SIM-Switcher, automated SIM switching with a Double (Dual) SIM adapter
--
Thank you all for voting me into the Community Council 2014-2016!

Please consider your membership / supporting Maemo e.V. and help to spread this by following/copying this link to your TMO signature:
[MC eV] Maemo Community eV membership application, http://talk.maemo.org/showthread.php?t=94257

editsignature, http://talk.maemo.org/profile.php?do=editsignature
 

The Following User Says Thank You to peterleinchen For This Useful Post:
Posts: 863 | Thanked: 213 times | Joined on Feb 2012 @ Goa
#24
in n900 it loses 1 percent every 5 or 10 min, is it normal? and in ideal mode where its just locked screen.
 
Posts: 25 | Thanked: 19 times | Joined on Apr 2014
#25
Originally Posted by peterleinchen View Post
Sure: top --help
or:
top -b -n 5 -d 2
will call top five times with a delay of 2 seconds. You may do whatever you want with the output ...
Sorry, didn't quite think of it! However, the periodic output doesn't appear to show anything too alarming. It's always Xorg or browserd at the top, and CPU usage looks quite normal at around 2~4% most of the time.

The service manual (the ones floating around here) says the cause could be failed BT circuitry. Also found that BT and WLAN share the same antenna, and WLAN works just fine. I cleaned up the contacts just to be sure, and it's still the same. At this point I think I can safely give up on getting back BT again and focus on purging dependent programs.

May yet have to get used to the 5-hour battery cycle with a couple of batteries and an external charger :-(.

Thank you.
 
Posts: 25 | Thanked: 19 times | Joined on Apr 2014
#26
With all the help here (and some more gathered from older posts), managed to squeeze a bit more out of my battery, It now lasts more than 10 hrs from full charge, which is well more than double of what it used to be. Still far from perfect, but here's a summary of what I did.

Plan was to get rid of bluetooth as completely as possible.

1. Started afresh by flashing into PR1.3, into CSSU-stable and kernel-power.
2. Purged these packages: bt-firmware connui-btsettings bluetooth-sysinfo connui-conndlgs-bluetooth connui-statusbar-bluetooth maemo-bluez-compat
3. Blacklisted the hci_h4p (this was vital) and bluetooth modules. This may have been unnecessary, but for good measure commented out the existing hci_h4p and bluetooth aliases under /etc/modprobe.d/

The bluetooth module no longer autoloads, and I see no bluetooth processes anymore.

What is still very strange is the zzztop and powertop outputs. zzztop reports a considerable C4 state, and powertop doesn't.

Output from powertop:
Code:
Powertop 1.13.3
Sleeping for 11 seconds before sampling
Collecting data for 45 seconds
Sample interval was 30m 45s 32745us

C#      | Ratio  | Avg/dura | Frequency | Ratio
--------+--------+----------+-----------+--------+
     C0 |  97.6% |          |  1150 MHz |   nan% |
     C1 |   0.0% |          | 
     C2 |   0.0% |    1.7ms | 
     C3 |   0.0% |  158.6ms | 
     C4 |   2.4% | 2306.6ms | 

IRQ#    | Activity   | Type           | Name
--------+------------+----------------+---------------------------
     56 |        269 |           INTC | i2c_omap
     37 |         72 |           INTC | gp
     57 |         51 |           INTC | i2c_omap
     11 |         36 |           INTC | prcm
     86 |          3 |           INTC | mmc1

PID#    | Activity   | Name           | Function Entry (Expire)
--------+------------+----------------+---------------------------
      0 |         43 |  <kernel core> | tick_nohz_restart_sched_tick (tick_sched_timer)
     38 |         16D|            awk | cpufreq_governor_dbs (delayed_work_timer_fn)
    724 |         12 |      bme_RX-51 | sys_timer_settime (posix_timer_fn)
    689 |          6 |           dsme | __enqueue_rt_entity (sched_rt_period_timer)
      0 |          5 |  <kernel core> | hrtimer_start (tick_sched_timer)
    724 |          3 |      bme_RX-51 | do_nanosleep (hrtimer_wakeup)
    724 |          3 |      bme_RX-51 | schedule_timeout (process_timeout)
    689 |          3 |           dsme | do_nanosleep (hrtimer_wakeup)
      1 |          3D|  <kernel core> | queue_delayed_work (delayed_work_timer_fn)
    603 |          2 |          mmcqd | queue_delayed_work (delayed_work_timer_fn)
    713 |          2D|<kernel module> | queue_delayed_work (delayed_work_timer_fn)
    724 |          1 |      bme_RX-51 | sys_timer_settime (posix_timer_fn)
      0 |          1 |  <kernel core> | addrconf_verify (addrconf_verify)
      0 |          1 |  <kernel core> | queue_delayed_work (delayed_work_timer_fn)
    778 |          1 |           hald | schedule_hrtimeout_range (hrtimer_wakeup)
   1699 |          1 |hildon-status-m | schedule_hrtimeout_range (hrtimer_wakeup)
    797 |          1 |            mce | schedule_hrtimeout_range (hrtimer_wakeup)
   2131 |          1 |       browserd | futex_wait (hrtimer_wakeup)
    925 |          1 | hald-addon-bme | schedule_hrtimeout_range (hrtimer_wakeup)
   1095 |          1 |          iphbd | schedule_hrtimeout_range (hrtimer_wakeup)
   2220 |          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:  99%|RET:   0%|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:  97%|RET:   1%|INA:   0%| ON:   0%| now:(ON)
   neon |OFF:  97%|RET:   1%|INA:   0%| ON:   0%| now:(ON)
    mpu |OFF:  97%|RET:   1%|INA:   0%| 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   539,  12.0/s | IRQ  431,   9.6/s | Timers  108,   2.4/s
HW wakeups       36,   0.8/s |     Real gp_timers expired   72,   1.6/s
Output from zzztop:
Code:
Detected 1 cpus
Detected 4 cpuidle states (3)
Sleeping for 10 seconds before collecting data for 45 seconds
Actually slept for 45.010s
C-state Information
===================
    |      CPU#0      |
 C# |  time  | avg/ms |
----+--------+--------+
 C0 |   1.6% |        |
 C1 |   0.0% |      0 |
 C2 |   0.2% |      1 |
 C3 |   1.5% |    337 |
 C4 |  96.6% |   1977 |

CPUfreq statistics
==================
Frequency |  CPU#0 |
----------+--------+
  250 MHz |  93.5% |
  600 MHz |   6.5% |

Interrupt statistics
====================
 INT | CPU#0 |
-----+-------+
  56 |   289 | INTC  i2c_omap
  37 |   157 | INTC  gp timer
  57 |    67 | INTC  i2c_omap
  11 |    46 | INTC  prcm
Summary: 12.4 interrupts/s total

Timer statistics
================
   PID | Activity |     task's comm | function
-------+----------+-----------------+---------
     0 |      127 |         swapper | tick_nohz_restart_sched_tick (tick_sched_timer)
    38 |       19D|             awk | cpufreq_governor_dbs (delayed_work_timer_fn)
   689 |        7 |            dsme | __enqueue_rt_entity (sched_rt_period_timer)
   724 |        4 |       bme_RX-51 | sys_timer_settime (posix_timer_fn)
   724 |        4 |       bme_RX-51 | schedule_timeout (process_timeout)
     0 |        4 |         swapper | hrtimer_start (tick_sched_timer)
   724 |        3 |       bme_RX-51 | sys_timer_settime (posix_timer_fn)
   724 |        3 |       bme_RX-51 | sys_timer_settime (posix_timer_fn)
   724 |        3 |       bme_RX-51 | sys_timer_settime (posix_timer_fn)
   724 |        3 |       bme_RX-51 | do_nanosleep (hrtimer_wakeup)
   713 |        3D|        modprobe | queue_delayed_work (delayed_work_timer_fn)
   689 |        3 |            dsme | do_nanosleep (hrtimer_wakeup)
     1 |        3D|         swapper | queue_delayed_work (delayed_work_timer_fn)
  1699 |        2 | hildon-status-m | schedule_hrtimeout_range (hrtimer_wakeup)
   797 |        2 |             mce | schedule_hrtimeout_range (hrtimer_wakeup)
   778 |        2 |            hald | schedule_hrtimeout_range (hrtimer_wakeup)
     0 |        2 |         swapper | queue_delayed_work (delayed_work_timer_fn)
  2243 |        1 |          zzztop | do_nanosleep (hrtimer_wakeup)
  1095 |        1 |           iphbd | schedule_hrtimeout_range (hrtimer_wakeup)
   925 |        1 |  hald-addon-bme | schedule_hrtimeout_range (hrtimer_wakeup)
   724 |        1 |       bme_RX-51 | sys_timer_settime (posix_timer_fn)
   603 |        1 |           mmcqd | queue_delayed_work (delayed_work_timer_fn)
    30 |        1 |           mount | setup_wb_timer (wb_timer_fn)
     1 |        1 |         swapper | inet_initpeers (peer_check_expire)

Context switches per task
=========================
  PID  | vol'try | non-vol | Cmdline
-------+---------+---------+--------
  2243 |       1 |       8 | /usr/bin/perl -w /usr/bin/zzztop -t=45 
  2118 |       1 |       0 | /usr/sbin/browserd -s 2118 -n browserui 
  2117 |       1 |       0 | /usr/bin/image-viewer                                                      
  2114 |       1 |       0 | /usr/bin/browser                                                           
  2110 |       1 |       0 | /usr/sbin/browserd -s 2110 -n RTComMessagingServer 
  2106 |       1 |       0 | /usr/bin/rtcom-messaging-ui                                                
  2101 |       1 |       1 | /usr/bin/rtcom-call-ui                                                     
  2097 |       1 |       0 | /usr/bin/osso-addressbook                                                  
  1776 |       1 |       0 | /usr/sbin/wlancond 
  1773 |       1 |       1 | /usr/bin/hildon-input-method 
  1764 |       5 |       1 | /usr/lib/tracker/trackerd 
  1699 |      92 |      17 | /usr/bin/hildon-status-menu                                                
  1687 |       2 |       0 | /usr/bin/mission-control 
  1095 |       1 |       0 | /usr/bin/iphbd 
  1066 |       1 |       0 | /usr/bin/systemui 
   925 |      16 |       0 | /usr/lib/hal/hald-addon-bme 
   797 |       5 |       7 | /sbin/mce --force-syslog 
   785 |       1 |       0 | /usr/sbin/csd -m -p call -p gprs -p info -p net -p sim -p simpb -p sms -p ss 
   780 |      10 |       0 | /usr/sbin/ohmd --no-daemon 
   778 |     146 |       2 | /usr/sbin/hald --verbose=no --daemon=no --use-syslog 
   738 |      46 |     146 | /usr/bin/dbus-daemon --system --nofork 
   724 |     119 |       5 | /usr/sbin/bme_RX-51 
   703 |      11 |       0 | /sbin/dsme-server -p /usr/lib/dsme/libstartup.so 
   689 |       6 |       0 | /sbin/dsme -p /usr/lib/dsme/libstartup.so 
   496 |       2 |       0 | <kmmcd>
    27 |      19 |       0 | <kondemand/0>
    14 |       1 |       0 | <pdflush>
     4 |       5 |       0 | <events/0>
     3 |     483 |       0 | <ksoftirqd/0>
This is battery-related but could well be irrelevant to the topic here. Just after I set up kernel-power (from extras-testing), I get the battery info twice, when I try these commands. Could this point to something?
Code:
Nokia-N900:~# lshal | grep 'perc'
  battery.charge_level.percentage = 95  (0x5f)  (int)
  battery.charge_level.percentage = 0  (0x0)  (int)
Code:
Nokia-N900:~# lshal | grep 'battery'
  battery.charge_level.capacity_state = 'ok'  (string)
  battery.charge_level.current = 8  (0x8)  (int)
  battery.charge_level.design = 8  (0x8)  (int)
  battery.charge_level.last_full = 0  (0x0)  (int)
  battery.charge_level.percentage = 95  (0x5f)  (int)
  battery.charge_level.unit = 'bars'  (string)
  battery.is_rechargeable = true  (bool)
  battery.present = true  (bool)
  battery.rechargeable.is_charging = false  (bool)
  battery.rechargeable.is_discharging = true  (bool)
  battery.remaining_time = 18000  (0x4650)  (int)
  battery.remaining_time.calculate_per_time = false  (bool)
  battery.reporting.current = 1190  (0x4a6)  (int)
  battery.reporting.design = 1242  (0x4da)  (int)
  battery.reporting.last_full = 0  (0x0)  (int)
  battery.reporting.unit = 'mAh'  (string)
  battery.type = 'pda'  (string)
  battery.voltage.current = 4083  (0xff3)  (int)
  battery.voltage.design = 4200  (0x1068)  (int)
  battery.voltage.unit = 'mV'  (string)
  info.capabilities = {'battery'} (string list)
  info.category = 'battery'  (string)
udi = '/org/freedesktop/Hal/devices/computer_power_supply_battery_rx51_battery'
  battery.charge_level.current = 0  (0x0)  (int)
  battery.charge_level.design = 5017  (0x1399)  (int)
  battery.charge_level.last_full = 0  (0x0)  (int)
  battery.charge_level.percentage = 0  (0x0)  (int)
  battery.charge_level.rate = 0  (0x0)  (int)
  battery.present = true  (bool)
  battery.reporting.design = 1262  (0x4ee)  (int)
  battery.reporting.technology = 'Li-ion'  (string)
  battery.reporting.unit = 'mAh'  (string)
  battery.technology = 'lithium-ion'  (string)
  battery.type = 'primary'  (string)
  battery.voltage.current = 3976  (0xf88)  (int)
  battery.voltage.design = 4200  (0x1068)  (int)
  battery.voltage.unit = 'mV'  (string)
  info.capabilities = {'battery'} (string list)
  info.category = 'battery'  (string)
  info.udi = '/org/freedesktop/Hal/devices/computer_power_supply_battery_rx51_battery'  (string)
  linux.sysfs_path = '/sys/class/power_supply/rx51-battery'  (string)
udi = '/org/freedesktop/Hal/devices/platform_rx51_battery'
  info.linux.driver = 'rx51-battery'  (string)
  info.product = 'Platform Device (rx51-battery)'  (string)
  info.udi = '/org/freedesktop/Hal/devices/platform_rx51_battery'  (string)
  linux.sysfs_path = '/sys/devices/platform/rx51-battery'  (string)
  platform.id = 'rx51-battery'  (string)

Last edited by codelad; 2014-07-18 at 07:09. Reason: Comment on duplicate battery reporting.
 

The Following 2 Users Say Thank You to codelad For This Useful Post:
pichlo's Avatar
Posts: 6,447 | Thanked: 20,981 times | Joined on Sep 2012 @ UK
#27
Originally Posted by codelad View Post
With all the help here (and some more gathered from older posts), managed to squeeze a bit more out of my battery, It now lasts more than 10 hrs from full charge, which is well more than double of what it used to be. Still far from perfect, but here's a summary of what I did.
Well done!

Those 10 hours are of constant use or idle? My phone can last for up to 2 days if I don't touch it, but that rarely happens. Normally I take it off the charger about 6:30 in the morning and by 22:00 the battery is at 25% at best. A two hours bath with editing and compiling some code on the phone is enough to suck 60+% of the battery juice. So 10 hours does not sound that outraous.

This is battery-related but could well be irrelevant to the topic here. Just after I set up kernel-power (from extras-testing), I get the battery info twice, when I try these commands. Could this point to something?
Code:
Nokia-N900:~# lshal | grep 'perc'
  battery.charge_level.percentage = 95  (0x5f)  (int)
  battery.charge_level.percentage = 0  (0x0)  (int)
I don't think so. I got that too:
Code:
~ $ lshal | grep "perc"
  battery.charge_level.percentage = 65  (0x41)  (int)
  battery.charge_level.percentage = 0  (0x0)  (int)
~ $
 

The Following 2 Users Say Thank You to pichlo For This Useful Post:
Posts: 25 | Thanked: 19 times | Joined on Apr 2014
#28
In my eagerness to purge bluetooth dependencies, I went a bit too far and deleted the battery management daemon (and several other packages with it). This nearly bricked my device - took numerous firmware flash attempts to finally get it to boot.

I've since tried to disable the bluetooth elements from pulseaudio, without much success. Commented out the bluetooth lines in /etc/pulse/default.pa, /etc/pulse/system.pa (this appears to work). Also tried deleting the bluetooth modules from /usr/lib/pulse-0.9.15/modules (this led to pulseaudio failing to start).

pichlo: Battery now lasts for roughly 10 hours (with 3G on, and about a couple of hours of SSHing into the phone over WLAN).

Still, the zzztop output shows considerable time in the C4 state and powertop shows a different picture.

Powertop:
Code:
Powertop 1.13.3
Sleeping for 11 seconds before sampling
Collecting data for 30 seconds
Sample interval was 30m 30s 33605us

C#      | Ratio  | Avg/dura | Frequency | Ratio
--------+--------+----------+-----------+--------+
     C0 |  98.4% |          |  1150 MHz |   nan% |
     C1 |   0.0% |    0.2ms | 
     C2 |   0.0% |    3.6ms | 
     C3 |   0.1% |  242.6ms | 
     C4 |   1.5% | 2813.8ms | 

IRQ#    | Activity   | Type           | Name
--------+------------+----------------+---------------------------
     56 |        191 |           INTC | i2c_omap
     37 |         62 |           INTC | gp
     11 |         39 |           INTC | prcm
     57 |         34 |           INTC | i2c_omap
     12 |          8 |           INTC | DMA
     86 |          3 |           INTC | mmc1
    202 |          1 |           GPIO | wl1251

PID#    | Activity   | Name           | Function Entry (Expire)
--------+------------+----------------+---------------------------
      0 |         42 |  <kernel core> | tick_nohz_restart_sched_tick (tick_sched_timer)
     38 |         11D|            awk | cpufreq_governor_dbs (delayed_work_timer_fn)
    736 |          6 |      bme_RX-51 | sys_timer_settime (posix_timer_fn)
    697 |          4 |           dsme | __enqueue_rt_entity (sched_rt_period_timer)
      0 |          3 |  <kernel core> | hrtimer_start (tick_sched_timer)
    697 |          3 |           dsme | do_nanosleep (hrtimer_wakeup)
    612 |          2 |          mmcqd | queue_delayed_work (delayed_work_timer_fn)
    736 |          2 |      bme_RX-51 | sys_timer_settime (posix_timer_fn)
    736 |          2 |      bme_RX-51 | do_nanosleep (hrtimer_wakeup)
    736 |          2 |      bme_RX-51 | schedule_timeout (process_timeout)
    732 |          2D|<kernel module> | queue_delayed_work (delayed_work_timer_fn)
      1 |          2D|  <kernel core> | queue_delayed_work (delayed_work_timer_fn)
   1151 |          1 |hildon-status-m | schedule_hrtimeout_range (hrtimer_wakeup)
    559 |          1 |         wl12xx | queue_delayed_work (delayed_work_timer_fn)
    710 |          1 |        syslogd | hrtimer_start (it_real_fn)
    783 |          1 |           hald | schedule_hrtimeout_range (hrtimer_wakeup)
     10 |          1 |    omap2_mcspi | neigh_add_timer (neigh_timer_handler)
    905 |          1 |           Xorg | schedule_hrtimeout_range (hrtimer_wakeup)
    956 |          1 | hald-addon-bme | schedule_hrtimeout_range (hrtimer_wakeup)
   1860 |          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:  98%|RET:   0%|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:  93%|RET:   4%|INA:   0%| ON:   0%| now:(ON)
   neon |OFF:  93%|RET:   4%|INA:   0%| ON:   0%| now:(ON)
    mpu |OFF:  93%|RET:   4%|INA:   0%| 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   427,  14.2/s | IRQ  338,  11.3/s | Timers   89,   3.0/s
HW wakeups       39,   1.3/s |     Real gp_timers expired   62,   2.1/s
zzztop:
Code:
Detected 1 cpus
Detected 4 cpuidle states (3)
Sleeping for 10 seconds before collecting data for 30 seconds
Actually slept for 30.020s
C-state Information
===================
    |      CPU#0      |
 C# |  time  | avg/ms |
----+--------+--------+
 C0 |   0.5% |        |
 C1 |   0.0% |        |
 C2 |   0.4% |      2 |
 C3 |   7.6% |    380 |
 C4 |  91.4% |   2495 |

CPUfreq statistics
==================
Frequency |  CPU#0 |
----------+--------+
  250 MHz | 100.0% |

Interrupt statistics
====================
 INT | CPU#0 |
-----+-------+
  56 |   164 | INTC  i2c_omap
  37 |    85 | INTC  gp timer
  11 |    53 | INTC  prcm
  57 |    34 | INTC  i2c_omap
Summary: 11.2 interrupts/s total

Timer statistics
================
   PID | Activity |     task's comm | function
-------+----------+-----------------+---------
     0 |       65 |         swapper | tick_nohz_restart_sched_tick (tick_sched_timer)
    38 |       10D|             awk | cpufreq_governor_dbs (delayed_work_timer_fn)
   697 |        4 |            dsme | __enqueue_rt_entity (sched_rt_period_timer)
     0 |        3 |         swapper | hrtimer_start (tick_sched_timer)
   736 |        2 |       bme_RX-51 | sys_timer_settime (posix_timer_fn)
   736 |        2 |       bme_RX-51 | sys_timer_settime (posix_timer_fn)
   736 |        2 |       bme_RX-51 | sys_timer_settime (posix_timer_fn)
   736 |        2 |       bme_RX-51 | sys_timer_settime (posix_timer_fn)
   736 |        2 |       bme_RX-51 | do_nanosleep (hrtimer_wakeup)
   736 |        2 |       bme_RX-51 | schedule_timeout (process_timeout)
   732 |        2D|        modprobe | queue_delayed_work (delayed_work_timer_fn)
   697 |        2 |            dsme | do_nanosleep (hrtimer_wakeup)
    10 |        2 |     omap2_mcspi | neigh_add_timer (neigh_timer_handler)
     1 |        2D|         swapper | queue_delayed_work (delayed_work_timer_fn)
  1870 |        1 |          zzztop | do_nanosleep (hrtimer_wakeup)
  1151 |        1 | hildon-status-m | schedule_hrtimeout_range (hrtimer_wakeup)
   905 |        1 |            Xorg | schedule_hrtimeout_range (hrtimer_wakeup)
   783 |        1 |            hald | schedule_hrtimeout_range (hrtimer_wakeup)
   736 |        1 |       bme_RX-51 | sys_timer_settime (posix_timer_fn)
   710 |        1 |         syslogd | hrtimer_start (it_real_fn)
    30 |        1 |           mount | setup_wb_timer (wb_timer_fn)
     0 |        1 |         swapper | addrconf_verify (addrconf_verify)

Context switches per task
=========================
  PID  | vol'try | non-vol | Cmdline
-------+---------+---------+--------
  1870 |       1 |       1 | /usr/bin/perl -w /usr/bin/zzztop 
  1151 |       2 |       2 | /usr/bin/hildon-status-menu                                                
   905 |       1 |       0 | /usr/bin/Xorg -logfile /tmp/Xorg.0.log -logverbose 1 -nolisten tcp -noreset -s 0 -core 
   821 |       1 |       2 | /sbin/mce --force-syslog 
   785 |       5 |       0 | /usr/sbin/ohmd --no-daemon 
   783 |      35 |       1 | /usr/sbin/hald --verbose=no --daemon=no --use-syslog 
   736 |      64 |       3 | /usr/sbin/bme_RX-51 
   713 |       6 |       0 | /sbin/dsme-server -p /usr/lib/dsme/libstartup.so 
   710 |       1 |       0 | /sbin/syslogd -n 
   697 |       4 |       0 | /sbin/dsme -p /usr/lib/dsme/libstartup.so 
    27 |      10 |       0 | <kondemand/0>
    14 |       1 |       0 | <pdflush>
     4 |       4 |       0 | <events/0>
     3 |       5 |       0 | <ksoftirqd/0>
Thank you.
 

The Following User Says Thank You to codelad For This Useful Post:
Posts: 2,290 | Thanked: 4,134 times | Joined on Apr 2010 @ UK
#29
The N900 it pretty un-brickable, a reflash will always put you straight if it's not a hardware issue.

When using powertop or zzztop it's best to take three samples and compare them to each other. This way you can see if there is a spike.
__________________

Wiki Admin
sixwheeledbeast's wiki
Testing Squad Subscriber
- mcallerx - tenminutecore - FlopSwap - Qnotted - zzztop - Bander - Fight2048 -


Before posting or starting a thread please try this.
 

The Following User Says Thank You to sixwheeledbeast For This Useful Post:
Posts: 25 | Thanked: 19 times | Joined on Apr 2014
#30
As I realised later, fimware flashing repeatedly failed due to a dead battery. And I had no means to find out since I had removed BME and the charging mechanism was badly broken. Eventually used an external battery to charge, and flash.

Did take about 8 samples with both powertop and zzztop and the general pattern remains the same. Does so even after flashing.

I bought the device used (and fairly battered) and as someone in a different thread pointed out, aggressive overclocking *may have* led to BT failure in their case [1]. Could well be the case here as well. My worst fear is that the device may be dying.

Thank you.

[1] - Possible but unlikely, as I've come to understand from subsequent posts in this thread.

Last edited by codelad; 2014-07-22 at 15:51. Reason: Added a note on overclocking and BT.
 
Reply


 
Forum Jump


All times are GMT. The time now is 01:40.