Thanks Michael and Kawashima-san,
i made PR #838 to fix this
it is currently available at https://github.com/open-mpi/ompi/pull/838
Cheers,
Gilles
On 8/27/2015 6:29 PM, Michael Knobloch wrote:
Dear OpenMPI developers,
I noticed a bug in the definition of the 3 MPI-3 RMA functions
MPI_Compare
Ralph,
what about :
- if only one interface is specified (e.g. *_if_include eth0), then bind
to that interface
- otherwise, bind to all interfaces
Mark, would that solve your issue ?
Cheers,
Gilles
On 8/28/2015 9:50 AM, Ralph Castain wrote:
I committed the change that prevents orte-submit
I committed the change that prevents orte-submit from binding a listener -
seems to work fine for me, so please let me know how it works for you.
The other issue - binding to all interfaces instead of only the ones specified
- is a little more troublesome. If we don’t bind to all interfaces, the
> On 27 Aug 2015, at 17:58 , Ralph Castain wrote:
> Okay, let me take a look
Thanks Ralph, please let me know if I can be of any assistance!
Hmmm…well, that isn’t right either :-)
I’ll fix this stuff tonight
> On Aug 27, 2015, at 2:49 PM, Mark Santcroos
> wrote:
>
> Hi Howard,
>
>> On 27 Aug 2015, at 17:59 , Mark Santcroos wrote:
>>> If you bind to ipogif0 then you should have much better luck, unless
>>> you're trying to have o
Hi Howard,
> On 27 Aug 2015, at 17:59 , Mark Santcroos wrote:
>> If you bind to ipogif0 then you should have much better luck, unless
>> you're trying to have open mpi span outside the cray HPN.
>
>
> Now you get me wondering. I actually played with both oob-tcp-if-include and
> -exclude , bu
Hi Howard,
> On 27 Aug 2015, at 17:48 , Howard Pritchard wrote:
> I think you're hitting an RSIP port limit.
Thats sounds like it indeed.
> If you bind to ipogif0 then you should have much better luck, unless
> you're trying to have open mpi span outside the cray HPN.
Now you get me wonderi
Okay, let me take a look
> On Aug 27, 2015, at 8:56 AM, Mark Santcroos
> wrote:
>
>
>> On 27 Aug 2015, at 17:44 , Ralph Castain wrote:
>> Just to be clear: you are saying that orte-submit is creating a listener? If
>> so, I can correct that as it doesn’t need to do so.
>
> Yes, I think it d
> On 27 Aug 2015, at 17:44 , Ralph Castain wrote:
> Just to be clear: you are saying that orte-submit is creating a listener? If
> so, I can correct that as it doesn’t need to do so.
Yes, I think it does indeed. At least its hitting that code path that looks
suspiciously like a listener! :)
Hi Mark,
I think you're hitting an RSIP port limit. If you bind to ipogif0 then you
should have much better luck, unless
you're trying to have open mpi span outside the cray HPN.
You can use the oob mca parameter:
oob-tcp-if-include ipogif0
You may want to put that in your .openmpi/mca-params.
Hi Mark
Just to be clear: you are saying that orte-submit is creating a listener? If
so, I can correct that as it doesn’t need to do so.
> On Aug 27, 2015, at 8:42 AM, Mark Santcroos
> wrote:
>
> Hi,
>
> For some reason that is currently still beyond me, I can't bind to INADDR_ANY
> for mo
Hi,
For some reason that is currently still beyond me, I can't bind to INADDR_ANY
for more than 74 ports on a Cray compute node, without getting EADDRINUSE.
This impacts my use of the oob_tcp_listener.c:create_listen() code on that
machine (through means of orte-submit).
I've implemented a proo
Kawashima-san,
you are right, I mixed MPI_Buffer_detach and MPI_Win_detach
sorry for the confusion
Cheers,
Gilles
On Thursday, August 27, 2015, Kawashima, Takahiro <
t-kawash...@jp.fujitsu.com> wrote:
> Gilles,
>
> > there is a comment in the source code to explain this.
>
> Could you point wh
Gilles,
> there is a comment in the source code to explain this.
Could you point where the comment is?
I can find a comment about MPI_Buffer_detach in
ompi/mpi/fortran/mpif-h/buffer_detach_f.c and
ompi/mpi/fortran/use-mpi-f08/buffer_detach.c files.
But the situation is different form MPI_Buffer_
iirc, the MPI_Win_detach discrepancy with the standard is intentional in
fortran 2008,
there is a comment in the source code to explain this.
On Thursday, August 27, 2015, Kawashima, Takahiro <
t-kawash...@jp.fujitsu.com> wrote:
> Oh, I also noticed it yesterday and was about to report it.
>
> An
Oh, I also noticed it yesterday and was about to report it.
And one more, the base parameter of MPI_Win_detach.
Regards,
Takahiro Kawashima
> Dear OpenMPI developers,
>
> I noticed a bug in the definition of the 3 MPI-3 RMA functions
> MPI_Compare_and_swap, MPI_Fetch_and_op and MPI_Raccumulate.
Dear OpenMPI developers,
I noticed a bug in the definition of the 3 MPI-3 RMA functions
MPI_Compare_and_swap, MPI_Fetch_and_op and MPI_Raccumulate.
According to the MPI standard, the origin_addr and compare_addr
parameters of these functions have a const attribute, which is missing
in OpenMPI's
I am lost ...
from ompi/mpi/fortran/mpif-h/profile/palltoall_f.c
void ompi_alltoall_f(char *sendbuf, MPI_Fint *sendcount, MPI_Fint *sendtype,
char *recvbuf, MPI_Fint *recvcount, MPI_Fint *recvtype,
MPI_Fint *comm, MPI_Fint *ierr)
{
[...]
c_ierr = M
I am pretty sure we fixed something very similar a couple months back.
The following is from "make check" with a recent (Tuesday night?) master
tarball.
CC unpack_ooo.o
PGC-S-0155-Empty initializer not supported
(/global/homes/h/hargrove/GSCRATCH/OMPI/openmpi-master-linux-x86_64-pgi-13.1
19 matches
Mail list logo
