On Wed, Nov 12, 2014 at 07:56:08PM +0900, Gilles Gouaillardet wrote:
> Folks,
>
> I found (at least) two issues with oshmem put if btl/vader is used with
> knem enabled :
>
> $ oshrun -np 2 --mca btl vader,self ./oshmem_max_reduction
>
On Wed, Nov 12, 2014 at 07:56:08PM +0900, Gilles Gouaillardet wrote:
> Folks,
>
> I found (at least) two issues with oshmem put if btl/vader is used with
> knem enabled :
>
> $ oshrun -np 2 --mca btl vader,self ./oshmem_max_reduction
>
I filed https://github.com/open-mpi/ompi/issues/268 for this issue.
On Nov 12, 2014, at 11:19 AM, Howard Pritchard wrote:
> HI Folks,
>
> I think this is a bug in the PSM MTL add_procs. The call to psm_ep_connect
> needs to be taking previously connected ep's into
HI Folks,
I think this is a bug in the PSM MTL add_procs. The call to psm_ep_connect
needs to be taking previously connected ep's into account,
much like what is done in the libfabric psm provider code.
Howard
2014-11-12 3:12 GMT-07:00 Rainer Keller :
> Dear
Hi folks
Those of you following the mailing lists probably know that we had hoped to
release 1.8.4 last Friday, but were unable to do so. We currently have a couple
of issues pending resolution, and our developers are badly “crunched” by final
prep for Supercomputing. We then will hit the US
It looks like we need to use prepare_dst() instead of prepare_src().
I also remember that there was a reason why prepare_src() is used with openib
btl.
I will be taking another look
Alex
Folks,
I found (at least) two issues with oshmem put if btl/vader is used with
knem enabled :
$ oshrun -np 2 --mca btl vader,self ./oshmem_max_reduction
--
SHMEM_ABORT was invoked on rank 0 (pid 11936, host=soleil) with
Dear Andrew,
no, this is not done with dynamically connecting jobs.
The failing tests use a communicator, which is setup by merging back an
intercommunicator (MPI_Intercomm_merge), which was first split from
MPI_COMM_WORLD (MPI_Intercomm_create).
Please see tst_comm.c:459
Best regards,
Rainer