On 17/02/2015 12:34, Benjamin Francis wrote:
> My biggest gripe at the moment is battery life, the battery life on my
> Flame only lasts half a day with normal use.
It's been hit-and-miss for me. Sometimes things run fine for a long
time, sometimes it gets drained very quickly. I imagine that something
is causing some stray app to keep burning CPU in the background under
> Are you having the same experience? Could you help debug where all the
> battery is going?
If you're experiencing the bug right now there's something you can do,
before putting your device to sleep turn on tracing for kernel
scheduling. On the device run these commands:
echo 1 >/sys/kernel/debug/tracing/events/sched/sched_stat_runtime/enable
echo 1 >/sys/kernel/debug/tracing/tracing_enabled
Disconnect it from the USB cable and put it aside for ten minutes or so,
what you feel is enough to expose the problem, then plug it back and
turn off tracing. On the device run:
echo 0 >/sys/kernel/debug/tracing/events/sched/sched_stat_runtime/enable
echo 0 >/sys/kernel/debug/tracing/tracing_enabled
Now dump the trace on your machine:
adb shell cat /sys/kernel/debug/tracing/trace > trace.log
Inside a list of all the tasks that run while the phone was asleep; look
for lines like this one:
b2g-7237  d..4 14390.388713: sched_stat_runtime: comm=b2g pid=7237
runtime=375157 [ns] vruntime=1741515666623 [ns]
This means that the thread with TID 7237 woke up and run for 375157ns.
If you find a b2g thread that woke up multiple times and the accumulated
runtime is significant (at least 100s of ms in total) then that's
probably our culprit. To figure out which application it belongs too run:
adb shell b2g-info -t
And look for the app containing the said TID.
I can cook up a script to automate this process but right now I'm too
busy with 2.2 blockers so you'll have to do it by hand :-/