This issue should be fixed now.
Please let me know if there are any other libfabric-related issues.
Thanks for your patience!
On Dec 17, 2014, at 4:22 PM, Jeff Squyres (jsquyres) wrote:
> On Dec 17, 2014, at 4:10 PM, Howard Pritchard wrote:
>
>> I'm fixing the libfabric m4 file. It just sa
On Dec 17, 2014, at 4:10 PM, Howard Pritchard wrote:
> I'm fixing the libfabric m4 file. It just says its happy if
> infiniband/verbs.h is there, then goes check some specific providers, but
> doesn't go back and check whether the specific providers are actually
> available.
That's the intend
I'm fixing the libfabric m4 file. It just says its happy if
infiniband/verbs.h is there, then goes check some specific providers, but
doesn't go back and check whether the specific providers are actually
available.
2014-12-17 12:53 GMT-07:00 Jeff Squyres (jsquyres) :
>
> On Dec 17, 2014, at 2:19
On Dec 17, 2014, at 2:19 PM, Howard Pritchard wrote:
> I did another mtt run with --disable-libfabric included on the configure line
> and still failed with the same problem, mtl/ofi thinks its okay to build...
FWIW: this problem is because the switch is --without-libfabric, not
--disable-lib
I believe the community took that position after oshmem caused disruption for a
while.
The ofi MTL has been in the tree for less than 24 hours. Please give us a
little time to sort out running on other people's systems.
On Dec 17, 2014, at 1:48 PM, Joshua Ladd wrote:
> Seem to me this shoul
On Dec 17, 2014, at 1:40 PM, Howard Pritchard wrote:
> I think the problem is that the libfabric configure is finding ibverbs.h
> header file and thinking everything is fine,
> so the mtl/ofi thinks it can build, even though there will be no libfabric
> for it to resolve symbols when the mtl
>
Then I would propose adding a ".ompi_ignore" to the 'ofi' component until
they get their configury straightened out.
Josh
On Wed, Dec 17, 2014 at 2:19 PM, Howard Pritchard
wrote:
>
> Hi Josh,
>
> I did another mtt run with --disable-libfabric included on the configure
> line and still failed wit
Hi Josh,
I did another mtt run with --disable-libfabric included on the configure
line and still failed with the same problem, mtl/ofi thinks its okay to
build...
Howard
2014-12-17 11:48 GMT-07:00 Joshua Ladd :
>
> Seem to me this should be disabled by default until folks can quiet the
> noise.
Seem to me this should be disabled by default until folks can quiet the
noise. If memory serves me, that's the position the community took with
OSHMEM.
Josh
On Wed, Dec 17, 2014 at 1:40 PM, Howard Pritchard
wrote:
>
> Jeff,
>
> I think the problem is that the libfabric configure is finding ibver
Jeff,
I think the problem is that the libfabric configure is finding ibverbs.h
header file and thinking everything is fine,
so the mtl/ofi thinks it can build, even though there will be no libfabric
for it to resolve symbols when the mtl
framework is opened.
As you'll see from the make output, th
Nope, its a Cray XC with good old (well new) MLNX cards installed on the
login and i/o nodes,
so libfab is likely getting built with ofed/ib provider - or at least
things it can build.
I'm rerunning the MTT script to diagnose the problem, just wondering if
others have seen this yet.
2014-12-17 10
Is this on a PSM-enabled cluster?
Can you send the full output from configure, the config.log, and the output
from "make"?
Are you building statically (i.e., libmpi.a)?
On Dec 17, 2014, at 12:04 PM, Howard Pritchard wrote:
> I noticed my MTT smoke test failed with todays master build:
>
>
12 matches
Mail list logo