The code generating the error is here:
in->sin_addr.s_addr = inet_addr(host);
if (in->sin_addr.s_addr == INADDR_ANY) {
return ORTE_ERR_BAD_PARAM;
}
The address is resolving to INADDR_ANY instead of a regular address. Does
cygwin require some other method for r
I am still seeing the same issue where I get some type of segv unless I disable
the coll ml component. This may be an issue at my end, but just thought I
would double check that we are sure this is fixed.
Thanks,
Rolf
>-Original Message-
>From: devel [mailto:devel-boun...@open-mpi.org]
noted on cygwin with 1.7.4 and on 1.7.5rc1
$ mpirun -n 4 ./hello_c.exe
[MATZERI:06212] [[62628,1],0] ORTE_ERROR_LOG: Bad parameter in file
/pub/devel/openmpi/openmpi-1.7.5rc1-1/src/openmpi-1.7.5rc1/orte/mca/oob/tcp/oob_tcp.c
at line 292
[MATZERI:05620] [[62628,1],1] ORTE_ERROR_LOG: Bad paramete
On 04/03/2014 20:35, Hjelm, Nathan T wrote:
Fixed and CMR'ed to 1.7.5.
-Nathan
confirmed
thanks
Fixed and CMR'ed to 1.7.5.
-Nathan
From: devel [devel-boun...@open-mpi.org] on behalf of Marco Atzeri
[marco.atz...@gmail.com]
Sent: Tuesday, March 04, 2014 7:38 AM
To: de...@open-mpi.org
Subject: Re: [OMPI devel] v1.7.5rc1 posted
On 02/03/2014 03:13, Ra
There was a rounding issue in basesmuma. If the control data happened to be
less than a page then we were trying to allocate 0 bytes. It should be fixed on
the trunk and has been CMR'ed to 1.7.5
-Nathan
Please excuse the horrible Outlook-style quoting. OWA sucks.
__
On 02/03/2014 03:13, Ralph Castain wrote:
In the usual place:
http://www.open-mpi.org/software/ompi/v1.7/
Please subject this to your best tests as we hope to roll this (plus bug fixes)
to 1.8.0 at the end of the month. This includes the new OSHMEM support, plus a
completely updated MPI-3 com
Hi,
coll/hcoll is Mellanox driven collective package.
coll/ml is managed/supported/developed by ORNL folks.
On Tue, Mar 4, 2014 at 1:06 PM, Ralph Castain wrote:
> Ummm...the "ml" stands for Mellanox. This is a component you folks
> contributed at some time. IIRC, the hcoll and/or bcol are mean
Ummm...the "ml" stands for Mellanox. This is a component you folks
contributed at some time. IIRC, the hcoll and/or bcol are meant to replace
it, but you folks would know best what to do with it.
On Tue, Mar 4, 2014 at 12:12 AM, Elena Elkina wrote:
> Hi,
>
> Recently I often meet hangs and seg
Hi,
Recently I often meet hangs and seg faults with different command lines and
there are "ml" functions in the stack trace.
When I just turn "ml" off by do -mca coll ^ml, problems disappear.
For example,
oshrun -np 4 --map-by node --display-map ./ring_oshmem
fails with seg fault while
oshrun -np
Yes, it is possible, but there is some different if I will do it this way -
With the current implementation (today into a trunk) if AC_RUN_IFELSE
fails => old code of RDMACM will rise,
And by way you suggest, if we postpone the decision to a run time and
the check fails =>
we have to abort
11 matches
Mail list logo
