Testing the current v1.7 tarball (1.7.5a1r30634), I get a failure when
building the oshmem examples.
I've confirmed that the same problem exists on trunk (so not a problem with
the CMR).
[...]
mpifort -g ring_usempi.f90 -o ring_usempi
** ring === End of Compilation 1 ===
1501-510 Compilation su
With Ralph's announcement that oshmem had been merged to v1.7 I started
tests on lots of systems.
When I found the problem described below, I tried the 1.7.4 release, I
found the problem exists there too!!
One system I tried is a fairly ancient x86-64/linux system w/ QLogic HCAs,
and thus builds a
Temporary workaround: -mca btl ^vader
On Feb 8, 2014, at 10:11 AM, Ralph Castain wrote:
> Sorry to say, some recent commit has broken the trunk:
>
> rhc@bend002 examples]$ mpirun -n 3 ./hello_c
> [bend001:22289] *** Process received signal ***
> [bend001:22289] Signal: Segmentation fault (11)
On Fri, Feb 07, 2014 at 10:08:48PM +, Jeff Squyres (jsquyres) wrote:
> Sweet -- +1 for CRIU support!
>
> FWIW, I see you modeled your configure.m4 off the blcr configure.m4, but I'd
> actually go with making it a bit simpler. For example, I typically structure
> my configure.m4's like this
Sorry to say, some recent commit has broken the trunk:
rhc@bend002 examples]$ mpirun -n 3 ./hello_c
[bend001:22289] *** Process received signal ***
[bend001:22289] Signal: Segmentation fault (11)
[bend001:22289] Signal code: Invalid permissions (2)
[bend001:22289] Failing at address: 0x7f354daaa00
The OSHMEM update is now in the 1.7.5 tarball - I would appreciate it if people
could exercise the tarball to ensure nothing broke. Note that shmem examples
are executing, but shmemrun is hanging instead of exiting. Mellanox is looking
into the problem.
For now, I just want to verify that MPI o
Sounds like it - I'll take a peek and see if I can spot it, otherwise will have
to wait for Jeff next week
On Feb 8, 2014, at 9:56 AM, Paul Hargrove wrote:
> A test of Friday night's trunk tarball is failing in the same manner.
> So, the CMR isn't the issue - the problem was never (fully?) fixe
A test of Friday night's trunk tarball is failing in the same manner.
So, the CMR isn't the issue - the problem was never (fully?) fixed in trunk.
-Paul
On Fri, Feb 7, 2014 at 9:06 PM, Paul Hargrove wrote:
> I tested the 1.7 tarball tonight.
> Jeff had indicated (
> http://www.open-mpi.org/com
I tested the 1.7 tarball tonight.
Jeff had indicated (
http://www.open-mpi.org/community/lists/devel/2014/01/13785.php) that the
problem I had reported w/ opal_path_nfs() and EPERM had been fixed in the
trunk.
Trac ticket #4125 indicated the fix was CMRed to v1.7
However, I still see the problem:
