You could confirm that it is the IPv6 loop by simply disabling IPv6 support -
configure with --disable-ipv6 and see if you still get the error messages
Thanks for continuing to pursue this!
Ralph
On Dec 16, 2009, at 8:41 PM, kevin.buck...@ecs.vuw.ac.nz wrote:
>> Just to say that I built the Net
> Just to say that I built the NetBSD OpenMPI 1.4 port from the CVS,
> so includsing all the recent work and get the exmaples to run, albeit
> still with the:
>
> opal_sockaddr2str failed:Unknown error (return code 4)
>
> non-fatal errors.
>
> As promised, I'll do bit more digging into this.
Here'
Ah crumb - I found the problem. Sigh.
I actually fixed this in the trunk over 5 months ago when the problem first
surfaced in my own testing, but it never came across to the stable release
branch. The problem is that we weren't serializing the comm_spawn requests, and
so the launch system gets
It depends on how Open MPI was built.
If Open MPI was built without plugins (i.e., all the plugins are slurped up
into libmpi and friends), then yes, applications need to link against librdmacm
to use the RDMA CM mode of OpenFabrics transport.
If Open MPI was built with plugins (which is the de
It is in a later version - pretty sure it made 1.3.3. IIRC, I added it at your
request :-)
On Dec 16, 2009, at 7:20 AM, jody wrote:
> Thanks for your reply
>
> That sounds good. I have Open-MPI version 1.3.2, and mpirun seems not
> to recognize the --xterm option.
> [jody@plankton tileopt]$ mpi
Thanks for your reply
That sounds good. I have Open-MPI version 1.3.2, and mpirun seems not
to recognize the --xterm option.
[jody@plankton tileopt]$ mpirun --xterm -np 1 ./boss 9 sample.tlf
--
mpirun was unable to launch the
Hi Ralph,
I am afraid I have been a little hasty!
I remake my tests with more care and I got the same error also with the
1.3.3 :-/
but in such version the error happens after some successful executions...
because of that I did not realize before!
Furthermore, I increased the number of levels of t
Depends on the version you are working with. If it includes the -xterm option,
then that option gets applied to the dynamically spawned procs too, so this
should be automatically taken care of...but in that case, you wouldn't need
your script to open an xterm anyway. You would just do:
mpirun -
Hi
Until now i always wrote applications for which the number of processes
was given on the command line with -np.
To debug these applications i wrote a script, run_gdb.sh which basically
open a xterm and starts gdb in it for my application.
This allowed me to have a window for each of the processe
