*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
runtime/orte_quit.lo*07:32
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 repo
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
> 07:32:17 CC runt
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
> `/scrap/jenkins/workspace/ompi-vendor-gerrit/label/hpc/orte'*07:32:17* CC
> runt
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 as the code
> is now i
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...
ompi/mca/btl/openib/configure.m4:3
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/
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. This is a significant
>> divergence from our
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 th
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 program, we try to catch signals
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 thread. We didn't
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
===
--- ompi/mca/pml/ob1/pml_ob
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 [mailto:devel-b
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 th
14 matches
Mail list logo
