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