Hi Stephan,
As you might have guessed, one of our goals has been to be able to run
the libpfm examples cleanly on Power.
multiplex.c gives odd error messages about calls to pfm_write_pmds and
pfm_write_pmcs depending on the options given. I tracked this down to
the allocation of the all_pmcs
Hi Stephane,
"stephane eranian" wrote on 01/08/2009 12:25:56
PM:
> Corey,
>
>
> On Thu, Jan 8, 2009 at 8:58 PM, Corey Ashford
> wrote:
> > Hello,
> >
> > It appears that I have forgotten to post a patch for this bug. This
was a
> > problem I had seen when booting the latest 2.6.28-rc6 kern
Corey,
On Thu, Jan 8, 2009 at 8:58 PM, Corey Ashford
wrote:
> Hello,
>
> It appears that I have forgotten to post a patch for this bug. This was a
> problem I had seen when booting the latest 2.6.28-rc6 kernel, where kernel
> function tracing was causing r4 to be corrupted because the perfmon c
Hello,
It appears that I have forgotten to post a patch for this bug. This was
a problem I had seen when booting the latest 2.6.28-rc6 kernel, where
kernel function tracing was causing r4 to be corrupted because the
perfmon code was called in the wrong order (pretty obscure bug!).
To elabor
Corey,
On Thu, Jan 8, 2009 at 2:16 AM, Corey J Ashford wrote:
> atomic_long_t is defined from atomic64_t which on power is defined as
> struct { long counter }.
>
> As an experiment, I tried changing perfmon_file.c to use atomic_long_read
> instead of atomic_read, and that fixed the problem. See
