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. Seeing how Power is a
big endian machine, it makes a lot of sense why atomic_read didn't work,
but did on x86_64.
Regards,
- Corey
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
[email protected]
"stephane eranian" <[email protected]> wrote on 01/07/2009 04:02:10
PM:
> On Thu, Jan 8, 2009 at 12:56 AM, Corey J Ashford <[email protected]>
wrote:
> > It's a 64-bit kernel App is 64-bits also, but I don't think that
matters.
> >
> Could you verify that sizeof(atomic_t) = sizeof(atomic_long_t) on your
system?
>
>
>
> > "stephane eranian" <[email protected]> wrote on 01/07/2009
03:54:51
> > PM:
> >
> >> Corey,
> >>
> >> On Thu, Jan 8, 2009 at 12:49 AM, Corey J Ashford
<[email protected]>
> > wrote:
> >> >
> >> > Yes, I didn't notice it before, but I am getting that warning.
> >> >
> >> > Before I received your email, I added some instrumentation to the
> > callback
> >> > pfm_buf_map_close() which is the function that sets
> > ctx->flags.mmap_nlock to
> >> > 1, and I see that file->f_count == 0. This would cause that
flagnot
> > to be
> >> > set, and then end up in the recursive lock inside of down_write().
> >> >
> >> I need to check on x86, but most likely I get f_count=1.
> >> The explanation about mmap_nlock can be found in
> >> perfmon_res.c. This is fairly complicated unfortunately.
> >>
> >> Are you compiling 64b-bit or 32-bit bit?
> >
> >
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
perfmon2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
