Paul and all,
before r32408, the environment/abort test from the ibm test suite
crashed with SIGSEGV.
there is no more crash after the fix :-)
that being said, i experience some (random) hangs on my VM :
--mca btl tcp,self => no hang
--mca btl sm,self or --mca btl vader,self => hang about 25% of
Paul,
i confirm ampersand was missing and this was a bug
/* a similar bug was fixed by Ralph in r32357 */
i commited r32408 in order to fix these three bugs.
i also took the liberty to replace the OMPI_CAST_RTE_NAME
with an inline function (only in debug mode) in order to get a
compiler warning
Hmm,
On a different Linux/x86-64 host things work as expected with '-lutil'
linked explicitly:
$ ./INST/bin/mpicc -showme BLD/examples/hello_c.c
pgcc BLD/examples/hello_c.c
-I/scratch/scratchdirs/hargrove/OMPI/openmpi-1.8.2rc3-linux-x86_64-pgi-14.1/INST/include
-L/opt/torque/4.2.7.h1/lib -Wl,-rpa
I've configured the 1.8.2rc3 tarball with "--enable-static
--disable-shared" on a fairly standard Linux/x86-64 platform. While there
are no problems on the same platform w/o these configure flags, with them I
cannot link any application codes.
$ mpicc -ghello_c.c -o hello_c
/global/homes/h/
On Sun, Aug 3, 2014 at 12:49 PM, Paul Hargrove wrote:
> BTW:
> Even with the "ignore_device=1" problem fixed, I can't get btl:openib
> running on x86.
> So, there may be additional reports in the next few hours.
>
That turned out to be the already known issue in 1.8.2rc3 that was since
fixed.
So
I have a pair of x86/linux (32 bit) hosts connected by Mellanox Tavor HCAs.
I have no idea if (or why) this has only appeared on this system, but I
find that blt:openib thinks the INI file says to ignore these HCAs. See
the 4th line below:
[pcp-j-5][[27705,1],0][/home/pcp1/phargrov/OMPI/openmpi
Paul,
imho, the root cause is a missing ampersand.
I will double check this from tomorrow only
Cheers,
Gilles
Ralph Castain wrote:
>Arg - that raises an interesting point. This is a pointer to a 64-bit number.
>Will uintptr_t resolve that problem on such platforms?
>
>
>On Aug 2, 2014, at 8:
Whether just adding a (uintptr_t) cast is sufficient or not depends on the
usage, and I don't pretend to have looked much deeper than seeing that this
macro is common to the line numbers in the warnings I quoted.
If the intent is to uniformly store a pointer then a (uintptr_t *) cast may
be approp
Arg - that raises an interesting point. This is a pointer to a 64-bit number.
Will uintptr_t resolve that problem on such platforms?
On Aug 2, 2014, at 8:12 PM, Paul Hargrove wrote:
> Looks like on a 32-bit platform a (uintptr_t) cast is desired in the
> OMPI_CAST_RTE_NAME() macro.
>
> Warnin
