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 impacts OProfile).
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.

Best regards,
Cyril


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@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 apparently
> 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 regarding
> 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.

Regards
Fred




Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920