On 9 December 2014 at 03:29, Howard Pritchard wrote:
> Hello Kevin,
>
> Could you try testing with Open MPI 1.8.3? There was a bug in 1.8.1
> that you are likely hitting in your testing.
>
> Thanks,
>
> Howard
Bingo!
Seems to have got rid of those messages.
Thanks.
Okay, they checked with my latest ORCM update and it is indeed working right
now - thx!
> On Dec 9, 2014, at 3:29 PM, Jeff Squyres (jsquyres)
> wrote:
>
> On Dec 9, 2014, at 3:08 PM, Ralph Castain wrote:
>
>> Oh I can configure and make just fine - I have nl installed on my machines.
>> The
Hi Folks,
I've tried running make distcheck on master and get failures for
opal_fifo/opal_lifo:
make[4]: Leaving directory
`/global/u2/h/hpp/ompi/openmpi-gitclone/_build/test/class'
make check-TESTS
make[4]: Entering directory
`/global/u2/h/hpp/ompi/openmpi-gitclone/_build/test/class'
make[5]
On Dec 9, 2014, at 3:08 PM, Ralph Castain wrote:
> Oh I can configure and make just fine - I have nl installed on my machines.
> The problem was hit by our folks at Intel, who didn’t have libnl and it
> didn’t kick out. So far as they tell me (as of 2 minutes ago), it still
> doesn’t, though I
Oh I can configure and make just fine - I have nl installed on my machines. The
problem was hit by our folks at Intel, who didn’t have libnl and it didn’t kick
out. So far as they tell me (as of 2 minutes ago), it still doesn’t, though
I’ll double-check with them.
> On Dec 9, 2014, at 1:59 PM,
HI Ralph,
Jeff fixed this in c40fd09. That's the problem I hit, in addition to
later not having psm_infinipath. After that commit,and commit cd0a54d
you should be able to config and make again.
Howard
2014-12-09 13:45 GMT-08:00 Ralph Castain :
> Just as an FYI: we discovered that libfabr
That was fixed earlier this morning.
On Dec 9, 2014, at 1:45 PM, Ralph Castain wrote:
> Just as an FYI: we discovered that libfabric requires libnl, and that the
> configure logic doesn’t kick you out if libnl isn’t found - you just fail
> during compile.
>
>
>> On Dec 9, 2014, at 6:29 AM, J
Just as an FYI: we discovered that libfabric requires libnl, and that the
configure logic doesn’t kick you out if libnl isn’t found - you just fail
during compile.
> On Dec 9, 2014, at 6:29 AM, Jeff Squyres (jsquyres)
> wrote:
>
> As I mentioned on the call a week ago, the usnic BTL has been
Yes, I know, but it might give a clue as to what goes wrong in the autogen
script (as the config path is erroneous), what is peculiar is that it only
happens for that sub-directory, so that should narrow the search down :)
I am glad it worked :)
2014-12-09 16:32 GMT+00:00 George Bosilca :
> Than
Thanks for the hint, it does fixes the problem. But it has to be applied on
the build directory after every configure ...
George.
On Tue, Dec 9, 2014 at 2:27 AM, Nick Papior Andersen
wrote:
> I experience the exact same thing.
> Please see my bug-report on this (and the work-around) here:
>
I would, too. Can you provide more detail than "it's broken"?
On Dec 9, 2014, at 7:59 AM, Howard Pritchard wrote:
> Well the build is broken again for cray. I'd like to have this stop.
>
>
> 2014-12-09 7:23 GMT-08:00 Ralph Castain :
> No problem - just wanted to make sure you were aware of
Just hadn't gotten around to it yet :). Still working on free list and
lifo stuff.
-Nathan
On Tue, Dec 09, 2014 at 07:56:04AM -0800, Ralph Castain wrote:
> Kewl - I wonder why it wasn’t fixed in trunk then?
>
>
> > On Dec 9, 2014, at 7:52 AM, Nathan Hjelm wrote:
> >
> >
> > Ralph, I correcte
Well the build is broken again for cray. I'd like to have this stop.
2014-12-09 7:23 GMT-08:00 Ralph Castain :
> No problem - just wanted to make sure you were aware of it.
>
>
> > On Dec 9, 2014, at 7:21 AM, Jeff Squyres (jsquyres)
> wrote:
> >
> > Yes, it did, because Howard's commit was wro
Kewl - I wonder why it wasn’t fixed in trunk then?
> On Dec 9, 2014, at 7:52 AM, Nathan Hjelm wrote:
>
>
> Ralph, I corrected this as part of the thread multiple pull request in
> 1.8.
>
> https://github.com/rhc54/ompi-release/commit/52823d592c3759c53ed63ed1f63fe200d2491220#diff-3673b21a7f42d
Ralph, I corrected this as part of the thread multiple pull request in
1.8.
https://github.com/rhc54/ompi-release/commit/52823d592c3759c53ed63ed1f63fe200d2491220#diff-3673b21a7f42dc0665ea4470b3171df1R510
-Nathan
On Tue, Dec 09, 2014 at 12:31:55AM -0800, Ralph Castain wrote:
>Hi Pascal
>
No problem - just wanted to make sure you were aware of it.
> On Dec 9, 2014, at 7:21 AM, Jeff Squyres (jsquyres)
> wrote:
>
> Yes, it did, because Howard's commit was wrong.
>
> I'm not sure what the exact problem was he was fixing (the commit message
> wasn't very specific), but the shell
Yes, it did, because Howard's commit was wrong.
I'm not sure what the exact problem was he was fixing (the commit message
wasn't very specific), but the shell variable names were already correct --
they are to indicate whether a specific provider (usnic, in this case) can be
built; not the libf
Fixing XRC for the newer ofed would be acceptable to me for the 1.8 series -
thanks!
> On Dec 9, 2014, at 5:07 AM, Gilles Gouaillardet
> wrote:
>
> Thanks Piotr,
>
> Based on the ompi community rules, a pr should be made vs the master, so code
> can be reviewed and shacked a bit.
> I alread
I believe this just reverted a commit last night from Howard that he needed to
fix the build on the Cray.
> On Dec 9, 2014, at 5:52 AM, git...@crest.iu.edu wrote:
>
> This is an automated email from the git hooks/post-receive script. It was
> generated because a ref change was pushed to the rep
As I mentioned on the call a week ago, the usnic BTL has been updated to use
libfabric (instead of verbs).
What is libfabric?
--> Think of it as a "next generation verbs" -- it's OS-bypass networking for a
wide range of network hardware, and libfabric contains many more capabilities
than the ve
Thanks Piotr,
Based on the ompi community rules, a pr should be made vs the master, so code
can be reviewed and shacked a bit.
I already prepared such a pr based on your patch and i will push it tomorrow.
Then the changes will be backported to the v1.8 branch, assuming this is not
considered as
Hi,
We indeed have a fix for XRC support on our branch at Bull and sorry I
neglected to contribute it, my bad…
I join here the patch on top of current v1.6.6 (should I rather
submit it as a pull request ?).
For v1.8+, a merge of the v1.6 code is not enough as openib connect
changed from xoob to
Pim,
if you configure OpenMPI with --with-hwloc=external (or something like
--with-hwloc=/usr) it is very likely
OpenMPI will use the same hwloc library (e.g. the "system" library) that
is used by SLURM
/* i do not know how Ubuntu packages OpenMPI ... */
The default (e.g. no --with-hwloc parame
Ah, ok so that was where the confusion came from, I did see hwloc in the SLURM
sources but couldn’t immediately figure out where exactly it was used. We will
try compiling openmpi with the embedded hwloc. Any particular flags I should
set?
> On 09 Dec 2014, at 09:30, Ralph Castain wrote:
>
>
Kewl - I’ll fix. Thanks!
> On Dec 9, 2014, at 12:32 AM, Pascal Deveze wrote:
>
> Hi Ralph,
>
> This in in the trunk.
>
> De : devel [mailto:devel-boun...@open-mpi.org] De la part de Ralph Castain
> Envoyé : mardi 9 décembre 2014 09:32
> À : Open MPI Developers
> Objet : Re: [OMPI devel] Patc
Hi Ralph,
This in in the trunk.
De : devel [mailto:devel-boun...@open-mpi.org] De la part de Ralph Castain
Envoyé : mardi 9 décembre 2014 09:32
À : Open MPI Developers
Objet : Re: [OMPI devel] Patch proposed: opal_set_using_threads(true) in
ompi/runtime/ompi_mpi_init.c is called to late
Hi Pasc
Hi Pascal
Is this in the trunk or in the 1.8 series (or both)?
> On Dec 9, 2014, at 12:28 AM, Pascal Deveze wrote:
>
>
> In case where MPI is compiled with --enable-mpi-thread-multiple, a call to
> opal_using_threads() always returns 0 in the routine btl_xxx_component_init()
> of the BTLs,
There is no linkage between slurm and ompi when it comes to hwloc. If you
directly launch your app using srun, then slurm will use its version of hwloc
to do the binding. If you use mpirun to launch the app, then we’ll use our
internal version to do it.
The two are completely isolated from each
In case where MPI is compiled with --enable-mpi-thread-multiple, a call to
opal_using_threads() always returns 0 in the routine btl_xxx_component_init()
of the BTLs, event if the application calls MPI_Init_thread() with
MPI_THREAD_MULTIPLE.
This is because opal_set_using_threads(true) in ompi/
The version that “lstopo --version” reports is the same (1.8) on all nodes, but
we may indeed be hitting the second issue. We can try to compile a new version
of openmpi, but how do we ensure that the external programs (e.g. SLURM) are
using the same hwloc version as the one embedded in openmpi?
Yeah, we’ve confirmed at Intel that OMPI won’t build with libtool 2.4.3+
I made Jeff aware of it, but we’re both too busy to dig into this before the
holiday.
> On Dec 8, 2014, at 11:27 PM, Nick Papior Andersen
> wrote:
>
> I experience the exact same thing.
> Please see my bug-report on thi
I experience the exact same thing.
Please see my bug-report on this (and the work-around) here:
http://www.open-mpi.org/community/lists/devel/2014/11/16371.php
2014-12-09 7:57 GMT+01:00 George Bosilca :
> After updating to the latest master (3a14c8e), I start having issues with
> the VPATH build
After updating to the latest master (3a14c8e), I start having issues with the
VPATH build on Mac OS X. The autogen.pl and configure succeeded but when make
is invoked I got the following error:
Making all in opal
Making all in include
/Applications/Xcode.app/Contents/Developer/usr/bin/make all-
33 matches
Mail list logo
