I don't think so. The Mellanox change that caused this issue should not be in
1.6.
-Nathan
On Fri, Jun 21, 2013 at 05:18:16PM +, Jeff Squyres (jsquyres) wrote:
> Does this need to go to v1.6?
>
> On Jun 21, 2013, at 11:59 AM, Nathan Hjelm wrote:
>
> > Found my original fix (still don't kn
Does this need to go to v1.6?
On Jun 21, 2013, at 11:59 AM, Nathan Hjelm wrote:
> Found my original fix (still don't know why I never pushed it) and I think
> George is correct. This should in both the single and multiple get cases.
>
> -Nathan
>
> On Fri, Jun 21, 2013 at 05:52:28PM +0200, Ge
Found my original fix (still don't know why I never pushed it) and I think
George is correct. This should in both the single and multiple get cases.
-Nathan
On Fri, Jun 21, 2013 at 05:52:28PM +0200, George Bosilca wrote:
> The amount of bytes received is atomically updated on the completion
> c
The amount of bytes received is atomically updated on the completion callback,
and the completion test is clearly spelled-out int the
recv_request_pml_complete_check function (of course minus the lock part). Rolf
I think your patch is correct.
That being said req_bytes_expected is a special val
I thought I fixed this problem awhile back (though looking at the code its
possible I never committed the fix). I will have to look through my local
repository and see what happened to that fix. Your fix might not work correctly
since a RGET can be broken up into multiple get operations. It may
I ran into a hang in a test in which the sender sends less data than the
receiver is expecting. For example, the following shows the receiver expecting
twice what the sender is sending.
Rank 0: MPI_Send(buf, BUFSIZE, MPI_INT, 1, 99, MPI_COMM_WORLD)
Rank 1: MPI_Recv(buf, BUFSIZE*2, MPI_INT, 0,
