On Thu, Jan 8, 2009 at 12:56 AM, Corey J Ashford <cjash...@us.ibm.com> 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" <eran...@googlemail.com> wrote on 01/07/2009 03:54:51 > PM: > >> Corey, >> >> On Thu, Jan 8, 2009 at 12:49 AM, Corey J Ashford <cjash...@us.ibm.com> > 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 perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
