[hwloc-devel] Create success (hwloc git 1.10.0-12-g1da4b76)

Creating nightly hwloc snapshot git tarball was a success. Snapshot: hwloc 1.10.0-12-g1da4b76 Start time: Tue Nov 11 21:04:21 EST 2014 End time: Tue Nov 11 21:05:48 EST 2014 Your friendly daemon, Cyrador

[hwloc-devel] Create success (hwloc git 1.9.1-13-g851532d)

Creating nightly hwloc snapshot git tarball was a success. Snapshot: hwloc 1.9.1-13-g851532d Start time: Tue Nov 11 21:02:55 EST 2014 End time: Tue Nov 11 21:04:20 EST 2014 Your friendly daemon, Cyrador

[hwloc-devel] Create success (hwloc git dev-275-g77fbe8f)

Creating nightly hwloc snapshot git tarball was a success. Snapshot: hwloc dev-275-g77fbe8f Start time: Tue Nov 11 21:01:02 EST 2014 End time: Tue Nov 11 21:02:45 EST 2014 Your friendly daemon, Cyrador

Re: [OMPI devel] 1.8.3 and PSM errors

Hi Folks, I remember in the psm provider for libfabric, that there is a check in the av_insert method for endpoints that had previously been inserted into the av. In the libfabric psm provider, a mask array is created and fed in to the psm_ep_connect call to handle ep's that were already

Re: [OMPI devel] 1.8.3 and PSM errors

> On Nov 11, 2014, at 17:13 , Jeff Squyres (jsquyres) > wrote: > >> More particularly, it looks like add_procs is being called a second time >> during MPI_Intercomm_create and being passed a process that is already >> connected (passed into the first add_procs call). Is

Re: [OMPI devel] 1.8.3 and PSM errors

Ralph, You're right that PSM wouldn't support dynamically connecting jobs. I don't think intercomm_create implies that though. For example you could split COMM_WORLD's group into two groups, then create an intercommunicator across those two groups. I'm guessing that's what this test is

Re: [OMPI devel] 1.8.3 and PSM errors

I thought PSM didn’t support dynamic operations such as Intercomm_create - yes? The PSM security key wouldn’t match between the two jobs, and so there is no way for them to communicate. Which is why I thought PSM can’t be used for dynamic operations at all, including comm_spawn and

Re: [OMPI devel] 1.8.3 and PSM errors

On Nov 11, 2014, at 4:56 PM, Friedley, Andrew wrote: > OK, I'm able to reproduce this now, not sure why I couldn't before. I took a > look at the diff of the PSM MTL from 1.6.5 to 1.8.1, and nothing is standing > out to me. > > Question more for the general group:

Re: [OMPI devel] 1.8.3 and PSM errors

OK, I'm able to reproduce this now, not sure why I couldn't before. I took a look at the diff of the PSM MTL from 1.6.5 to 1.8.1, and nothing is standing out to me. Question more for the general group: Did anything related to the behavior/usage of MTL add_procs() change in this time window?

[OMPI devel] Open MPI face-to-face devel meeting

On the call today, we decided the final dates/location of the OMPI face-to-face developers meeting: - Dates: Jan 27-29, 2015 (Tue-Wed) - Location: Cisco Richardson, Texas facility (outside Dallas) See the wiki page for more details: 1. Put your name on the wiki if you plan to attend 2. Start

Re: [OMPI devel] 1.8.3 and PSM errors

Using the intel test suite I can reproduce it for example with: $ mpirun --np 2 --map-by ppr:1:node `pwd`/src/MPI_Allgatherv_c MPITEST info (0): Starting MPI_Allgatherv() test MPITEST info (0): Node spec MPITEST_comm_sizes[6]=2 too large, using 1 MPITEST info (0): Node spec

Re: [OMPI devel] 1.8.3 and PSM errors

I think it would help understand this if you isolated it down to a single test that is failing, rather than just citing an entire test suite. For example, we know that the many-to-one test is never going to pass, regardless of transport. We also know that the dynamic tests will fail with PSM as

Re: [OMPI devel] 1.8.3 and PSM errors

Some more information about our PSM troubles. Using 1.6.5 the test suite still works. It fails with 1.8.3 and 1.8.4rc1. As long as all processes are running on one node it also works. As soon as one process is running on a second node it fails with the previously described errors. I also tried

Re: [OMPI devel] OMPI devel] Jenkins vs master (and v1.8)

rhel6.4 we can provide ssh access to interested parties. On Tue, Nov 11, 2014 at 2:01 PM, Gilles Gouaillardet < gilles.gouaillar...@gmail.com> wrote: > Thanks Mike, > > BTW what is the distro running on your test cluster ? > > Mike Dubman wrote: > ok, I disabled vader

Re: [OMPI devel] OMPI devel] Jenkins vs master (and v1.8)

Thanks Mike, BTW what is the distro running on your test cluster ? Mike Dubman wrote: >ok, I disabled vader tests in SHMEM and it passes. > >it can be requested from jenkins by specifying "vader" in PR comment line. > > >On Tue, Nov 11, 2014 at 11:04 AM, Gilles

Re: [OMPI devel] Jenkins vs master (and v1.8)

ok, I disabled vader tests in SHMEM and it passes. it can be requested from jenkins by specifying "vader" in PR comment line. On Tue, Nov 11, 2014 at 11:04 AM, Gilles Gouaillardet < gilles.gouaillar...@iferc.org> wrote: > Mike, > > that will remove the false positive, but also remove an

Re: [OMPI devel] Jenkins vs master (and v1.8)

Mike, that will remove the false positive, but also remove an important piece of information : there is something wrong with the master. would you mind discussion this on the weekly call ? Cheers, Gilles On 2014/11/11 17:38, Mike Dubman wrote: > how about if I will disable the failing test(s)

Re: [OMPI devel] Jenkins vs master (and v1.8)

how about if I will disable the failing test(s) and make jenkins to pass? It will help us to make sure we don`t break something that did work before? On Tue, Nov 11, 2014 at 7:02 AM, Gilles Gouaillardet < gilles.gouaillar...@iferc.org> wrote: > Mike, > > Jenkins runs automated tests on each pull

[OMPI devel] Jenkins vs master (and v1.8)

Mike, Jenkins runs automated tests on each pull request, and i think this is a good thing. recently, it reported a bunch of failure but i could not find anything to blame in the PR itself. so i created a dummy PR https://github.com/open-mpi/ompi/pull/264 with git commit --allow-empty and waited