This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
Some additional data:
Without threads it still hangs, similar behavior as before.
All of the tests were run on a system running FC11 with X5550 processors.
I just reran on a node of a RHEL 5.3 cluster with E5530 processors (dual
- openmpi 1.3.4 and gcc 4.1.2
- No issues: connectivity_c works through np = 128
- openmpi 1.3.4 and gcc 4.4.0
- Hangs as before
Anything else you want me to try;-)?
On Thu, Dec 10, 2009 at 5:20 PM, Jeff Squyres <jsquyres_at_[hidden]> wrote:
> On Dec 10, 2009, at 5:01 PM, Gus Correa wrote:
> > > Just a quick interjection, I also have a dual-quad Nehalem system, HT
> > > on, 24GB ram, hand compiled 1.3.4 with options: --enable-mpi-threads
> > > --enable-mpi-f77=no --with-openib=no
> > >
> > > With v1.3.4 I see roughly the same behavior, hello, ring work,
> > > connectivity fails randomly with np >= 8. Turning on -v increased the
> > > success, but still hangs. np = 16 fails more often, and the hang is
> > > random in which pair of processes are communicating.
> > >
> > > However, it seems to be related to the shared memory layer problem.
> > > Running with -mca btl ^sm works consistently through np = 128.
> Note, too, that --enable-mpi-threads "works" but I would not say that it is
> production-quality hardened yet. IBM is looking into thread safety issues
> to harden up this code. If the same hangs can be observed without
> --enable-mpi-threads, that would be a good data point.
> Jeff Squyres
> users mailing list