Hello,
I am playing with mx__regcache_clean() in Open-MX so as to have OpenMPI
cleanup the Open-MX regcache when needed. It causes some deadlocks since
OpenMPI intercepts Open-MX' own free() calls. Is there a "safe" way to
have Open-MX free/munmap calls not invoke OpenMPI interception hooks? Or
Hi list,
We are currently experiencing deadlocks when using communicators other
than MPI_COMM_WORLD. So we made a very simple reproducer (Comm_create then
MPI_Barrier on the communicator - see end of e-mail).
We can reproduce the deadlock only with openib and with at least 8 cores
(no
what version of OpenMPI did you use? Patch #21970 should have fixed this
issue on the trunk...
Thanks
Edgar
Sylvain Jeaugey wrote:
Hi list,
We are currently experiencing deadlocks when using communicators other
than MPI_COMM_WORLD. So we made a very simple reproducer (Comm_create
then
You were faster to fix the bug than I was to send my bug report :-)
So I confirm : this fixes the problem.
Thanks !
Sylvain
On Mon, 21 Sep 2009, Edgar Gabriel wrote:
what version of OpenMPI did you use? Patch #21970 should have fixed this
issue on the trunk...
Thanks
Edgar
Sylvain Jeaugey
On Sep 21, 2009, at 5:50 AM, Brice Goglin wrote:
I am playing with mx__regcache_clean() in Open-MX so as to have
OpenMPI
cleanup the Open-MX regcache when needed. It causes some deadlocks
since
OpenMPI intercepts Open-MX' own free() calls. Is there a "safe" way to
have Open-MX free/munmap
Ick; I appreciate Lisandro's quandry, but don't quite know what to do.
How about keeping libltdl fvisibility=hidden inside mpi4py?
On Sep 17, 2009, at 11:16 AM, Josh Hursey wrote:
So I started down this road a couple months ago. I was using the
lt_dlopen() and friends in the OPAL CRS self
I was kind of amazed no one else managed to run into this but it was
brought to my attention that compiling OMPI with Intel compilers and
visibility on that the MPIR_Breakpoint symbol was not being exposed. I
am assuming this is due to MPIR_Breakpoint not being ORTE or OMPI_DECLSPEC'd
Do
Jeff Squyres wrote:
> On Sep 21, 2009, at 5:50 AM, Brice Goglin wrote:
>
>> I am playing with mx__regcache_clean() in Open-MX so as to have OpenMPI
>> cleanup the Open-MX regcache when needed. It causes some deadlocks since
>> OpenMPI intercepts Open-MX' own free() calls. Is there a "safe" way to
I see it declared "extern" in orte/tools/orterun/debuggers.h, but not
DECLSPEC'd
FWIW: LANL uses intel compilers + totalview on a regular basis, and I
have yet to hear of an issue.
On Sep 21, 2009, at 7:03 AM, Terry Dontje wrote:
I was kind of amazed no one else managed to run into this
Does declspec matter for executables? (I don't recall)
On Sep 21, 2009, at 9:15 AM, Ralph Castain wrote:
I see it declared "extern" in orte/tools/orterun/debuggers.h, but not
DECLSPEC'd
FWIW: LANL uses intel compilers + totalview on a regular basis, and I
have yet to hear of an issue.
On
Ralph Castain wrote:
I see it declared "extern" in orte/tools/orterun/debuggers.h, but not
DECLSPEC'd
FWIW: LANL uses intel compilers + totalview on a regular basis, and I
have yet to hear of an issue.
It actually will work if you attach to the job or if you are not relying
on the
Do you just want to wait for the ummunotify stuff in OMPI? I'm half
done making a merged "linux" memory component (i.e., it merges the
ptmalloc2 component with the new ummunotify stuff).
It won't help for kernels <2.6.32, of course. :-)
On Sep 21, 2009, at 9:11 AM, Brice Goglin wrote:
Jeff Squyres wrote:
> Do you just want to wait for the ummunotify stuff in OMPI? I'm half
> done making a merged "linux" memory component (i.e., it merges the
> ptmalloc2 component with the new ummunotify stuff).
>
> It won't help for kernels <2.6.32, of course. :-)
Yeah that's another solution
Hi,
According to our TotalView person, PGI and Intel versions of OMPI
1.3.3 are not working properly. She noted that 1.2.8 and 1.3.2 work
fine.
Thanks,
Samuel K. Gutierrez
On Sep 21, 2009, at 7:19 AM, Terry Dontje wrote:
Ralph Castain wrote:
I see it declared "extern" in
As a workaround, Lisandro could just pre-seed the cache variables of the
respective configure tests that come out wrong.
./configure lt_cv_dlopen_self=yes lt_cv_dlopen_self_static=yes
HTH.
Cheers,
Ralf
* Jeff Squyres wrote on Mon, Sep 21, 2009 at 02:45:28PM CEST:
> Ick; I appreciate
Hi Jeff,
Sorry about the ambiguity. I just had another conversation with our
TotalView person and the problem -seems- to be unrelated to OMPI.
Guess I jumped the gun...
Thanks,
Samuel K. Gutierrez
On Sep 21, 2009, at 8:58 AM, Jeff Squyres wrote:
Can you more precisely define "not
Hi
I am trying to run open-mpi 1.3.3. between a linux box running ubuntu
server v.9.04 and a Macintosh. I have configured openmpi with the
following options.:
./configure --prefix=/usr/local/ --enable-heterogeneous --disable-shared
--enable-static
When both the machines are connected to the
On Sep 20, 2009, at 6:12 PM, Samuel Thibault wrote:
> Also, we have __hwloc_restrict everywhere in the public API, but
also in
> the manpages? Should we convert the latter into a regular "restrict"
> keyword ?
I had tried before already through the .cfg and that didn't work.
Since
we now
Jeff Squyres, le Mon 21 Sep 2009 08:22:06 -0400, a écrit :
> FWIW, is there a reason we're not using AC_C_RESTRICT in
> configure.ac? This allows you to use "restrict" in C code everywhere;
> it'll be #defined to something acceptable by the compiler if
> "restrict" itself is not.
Our
On Sep 21, 2009, at 8:44 AM, Samuel Thibault wrote:
> FWIW, is there a reason we're not using AC_C_RESTRICT in
> configure.ac? This allows you to use "restrict" in C code
everywhere;
> it'll be #defined to something acceptable by the compiler if
> "restrict" itself is not.
Our
Jeff Squyres, le Mon 21 Sep 2009 08:51:35 -0400, a écrit :
> On Sep 21, 2009, at 8:44 AM, Samuel Thibault wrote:
>
> >> FWIW, is there a reason we're not using AC_C_RESTRICT in
> >> configure.ac? This allows you to use "restrict" in C code
> >everywhere;
> >> it'll be #defined to something
Jeff Squyres, le Mon 21 Sep 2009 10:04:21 -0400, a écrit :
> On Sep 21, 2009, at 9:40 AM, Samuel Thibault wrote:
> >> So it should be ok to use AC_C_RESTRICT then, right?
> >
> >But then we can't expose restrict in installed headers since we don't
> >know _whether_ and how it is defined.
> >
>
>
Jeff Squyres, le Mon 21 Sep 2009 12:31:41 -0400, a écrit :
> On Sep 21, 2009, at 10:42 AM, Samuel Thibault wrote:
> >It's part of the language starting from C99 only. An application could
> >enable non-C99 mode where it becomes undefined, you can never know.
>
> That is a decade old, no? ;-)
Samuel Thibault, le Mon 21 Sep 2009 19:33:11 +0200, a écrit :
> Jeff Squyres, le Mon 21 Sep 2009 12:31:41 -0400, a écrit :
> > On Sep 21, 2009, at 10:42 AM, Samuel Thibault wrote:
> > >It's part of the language starting from C99 only. An application could
> > >enable non-C99 mode where it becomes
24 matches
Mail list logo
