oprofile and ARM A9 hardware counter
Will Deacon
will.deacon at arm.com
Tue Apr 3 12:07:06 EDT 2012
On Tue, Apr 03, 2012 at 03:27:52PM +0100, Kevin Hilman wrote:
> Hi Will,
Hi Kevin,
> Will Deacon <will.deacon at arm.com> writes:
> > The problem is, trying to boot this on my pandaboard results in a hang (see
> > dmesg below). Even worse, the problem isn't easily bisectable since rebuilding
> > a working image can give you something that no longer boots and I haven't found
> > a reliable way to cause the lockup.
> >
> > I'll take JTAG for a whirl to see where we are. If anything looks wrong in
> > my dmesg, please shout (there are plenty of things in there that look like
> > they've gone awry).
>
> Not sure why it hangs for you, but it worked for me both with your
> branch on v3.3 and merging with v3.4-rc1[1]
Thanks for testing that. It turns out that updating my x-loader (it was
pretty ancient) fixed the boot hang, though I'm not sure I want to know why!
> # perf stat sleep 1
>
> Performance counter stats for 'sleep 1':
>
> 9.582520 task-clock # 0.009 CPUs utilized
> 1 context-switches # 0.104 K/sec
> 0 CPU-migrations # 0.000 K/sec
> 147 page-faults # 0.015 M/sec
> 5096283 cycles # 0.532 GHz
> 607876 stalled-cycles-frontend # 11.93% frontend cycles idle
> 3285045 stalled-cycles-backend # 64.46% backend cycles idle
> 2722485 instructions # 0.53 insns per cycle
> # 1.21 stalled cycles per insn
> 259247 branches # 27.054 M/sec
> 84274 branch-misses # 32.51% of all branches
Right. Can you confirm whether the PMU/CTI interrupts fire for you please?
Just run perf top and look at /proc/interrupts while it's running. You
should see a couple of arm-pmu entries in there and hopefully numbers > 0.
For me, my earlier mis-diagnosis has turned out to be true and I can only
see PMU interrupts if I apply the SWSUSP patch, which Santosh says will
break pm.
Cheers,
Will
More information about the linux-arm-kernel
mailing list