11.07 oprofile on panda busted?
c-bianconi at ti.com
Fri Sep 16 09:30:55 UTC 2011
I don't think that the A9 issue is the same as the A8. However, effects are
the same i.e. it's hard to use PMU.
I cannot communicate the A9 errata document as-is due to legal stuff but I
belive that I can explain the issue.
The issue happens when counters are in overflow (then not sure that this
Theoritically, an interrupt should fire in this case. In reality, this
interrupt is lost randomly.
The ARM proposed workaround is to use 2 counters: counter 0 and counter1
initialized at counter0+1. If one interrupt is lost, the other one should
fire just after.
We have noticed that this could not be sufficient and that a third counter
should be used to have close to 0% of the interrupts lost.
Note: This HW issue has been fixed by ARM quite "late", so I think that most
of the devices on the market should be impacted.
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet.
036 420 040 R.C.S Antibes. Capital de EUR 753.920
On Thu, Sep 15, 2011 at 8:02 PM, Turgis, Frederic <f-turgis at ti.com> wrote:
> > Once the interrupt issue is resolved I might suggest sampling cpu-cycles
> as a workaround to real-time sampling granularity, except that there
> > is an issue with reliably getting interrupts from the PMU. Does anyone
> know if this is still a problem in the A9 (I've only seen it discussed
> > the A8)? If it's still an issue I think it simply kills using PMU event
> counters with oprofile.
> We just had an intern who experienced the same on A9, it required minimum 3
> counters counting same event to get at least 1 interrupt on counter overflow
> :-( I put in the loop Cyril, who was mentoring him, to confirm but it is
> probably still in A9 errata list.
> Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve
> Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the linaro-dev