Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r30860 - in trunk/ompi/mca: btl/usnic rte

Just to clarify my point, since the 1.7 branch was mentioned in this thread. I didn't worry about USNIC calling abort because, as Jeff pointed out, we do so in other places. However, I do believe that we shouldn't be doing so (including in orte) because it isn't the role of a library to abort

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r30860 - in trunk/ompi/mca: btl/usnic rte

It could. I added that argument 4 years ago to support by my failover work with the BFO. It was a way for a BTL to pass some type of string back to the PML telling the PML who it was for verbose output to understand what was happening. >-Original Message- >From: devel

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r30860 - in trunk/ompi/mca: btl/usnic rte

Speaking of which, shouldn't the OB1 error handler send the error message string that it received as the 4th param to ompi_rte_abort() so that it can be printed out? Index: ompi/mca/pml/ob1/pml_ob1.c === ---

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r30860 - in trunk/ompi/mca: btl/usnic rte

FWIW, the following BTLs all have calls to abort() or ompi_rte_abort() within them: - usnic - openib - portals4 - the btl base itself On Feb 27, 2014, at 7:16 AM, Ralph Castain wrote: >> The majority of places we call abort in this commit is actually down in a >> progress

Re: [OMPI devel] Open MPI's 'mpiexec' trash output of program being aborted?

Not intentional, but I suspect it's a race condition you are seeing. I'll have to look to see where it is getting lost On Feb 27, 2014, at 9:32 AM, Paul Kapinos wrote: > Dear Open MPI developer, > > > Please take a look at the attached 'program'. > > In this

[OMPI devel] Open MPI's 'mpiexec' trash output of program being aborted?

Dear Open MPI developer, Please take a look at the attached 'program'. In this program, we try to catch signals send from outside, and "handle" them. In case of different signals different output has to be produced. When you start this file directly, or using 'mpiexec' from Intel MPI, and

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r30860 - in trunk/ompi/mca: btl/usnic rte

On Feb 27, 2014, at 6:58 AM, Jeff Squyres (jsquyres) wrote: > On Feb 27, 2014, at 3:33 AM, George Bosilca wrote: > >> I’m concerned about your usage of abort here. Looking at the code I noticed >> that you call RTE_ABORT deep inside the BTL stack.

[OMPI devel] warning in openib BTL

I'm also seeing these warnings this morning: connect/btl_openib_connect_rdmacm.c:369:5: warning: "BTL_OPENIB_RDMACM_IB_ADDR" is not defined -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

[OMPI devel] autoconf warnings: openib BTL

I'm seeing this warning this morning: - configure.ac:1139: warning: AC_RUN_IFELSE called without default to allow cross c\ ompiling ../../lib/autoconf/general.m4:2748: AC_RUN_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r30860 - in trunk/ompi/mca: btl/usnic rte

On Feb 27, 2014, at 3:33 AM, George Bosilca wrote: > I’m concerned about your usage of abort here. Looking at the code I noticed > that you call RTE_ABORT deep inside the BTL stack. This is a significant > divergence from our current behavior (except for USNIC apparently

Re: [OMPI devel] compile error in v1.7

yep, now it fine. thx On Thu, Feb 27, 2014 at 4:43 PM, Ralph Castain wrote: > you need to update your repo > > On Feb 26, 2014, at 9:55 PM, Mike Dubman wrote: > > *07:32:17* make[2]: Entering directory >

Re: [OMPI devel] compile error in v1.7

you need to update your repo On Feb 26, 2014, at 9:55 PM, Mike Dubman wrote: > 07:32:17 make[2]: Entering directory > `/scrap/jenkins/workspace/ompi-vendor-gerrit/label/hpc/orte' > 07:32:17 CC runtime/orte_finalize.lo > 07:32:17 CC runtime/orte_init.lo

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r30860 - in trunk/ompi/mca: btl/usnic rte

Guys, I’m concerned about your usage of abort here. Looking at the code I noticed that you call RTE_ABORT deep inside the BTL stack. This is a significant divergence from our current behavior (except for USNIC apparently as the code is now in the 1.7). The BTLs are not deciders, but merely

[OMPI devel] compile error in v1.7

*07:32:17* make[2]: Entering directory `/scrap/jenkins/workspace/ompi-vendor-gerrit/label/hpc/orte'*07:32:17* CC runtime/orte_finalize.lo*07:32:17* CC runtime/orte_init.lo*07:32:17* CC runtime/orte_locks.lo*07:32:17* CC runtime/orte_globals.lo*07:32:18* CC