Hi Doug
The changes are rather far-reaching. We essentially revamped the entire RTE
to switch from an event-driven architecture to one based on sequential
logic. This had large benefits, but the GPR was the casualty. Remember, the
aim for the past year has been to create a dedicated "lean, mean OM
r17440 fix this issue. It's too easy :)
george.
On Feb 12, 2008, at 9:15 PM, MPI Team wrote:
ERROR: Command returned a non-zero exist status
make -j 4 distcheck
Start time: Tue Feb 12 21:00:13 EST 2008
End time: Tue Feb 12 21:15:34 EST 2008
=
=
Wellbest laid plans of mice and men, as they say.
We were just having -way- too much fun here at IBM today going over the new
ORTE design, planning for future scalability changes, etc., so American
decided to cancel my flight back home! So thoughtful!
I will be spending my Wed (hopefully!) en
Were these supposed to cover the time required for pinning and
unpinning?
Can you explain why you think they're unnecessary?
On Feb 12, 2008, at 5:27 AM, Gleb Natapov wrote:
Hi,
I am planning to commit the following patch. Those two progress()
calls
are responsible for most of our deep
Hmm; I'm not sure.
distclean will fail in a tarball or SVN checkout if you do --enable-
contrib-no-build=vt. So it's not a developer-only artifact.
I don't know what the Right solution is, though. :-\
On Feb 12, 2008, at 9:22 AM, Josh Hursey wrote:
Good points about 'distclean' versus '
I see that in the OOB CPC for the openib BTL, when setting up the send
side of the QP, we set the rnr_retry value depending on whether the
remote receive queue is a per-peer or SRQ:
- SRQ: btl_openib_rnr_retry MCA param value
- PP: 0
The rationale given in a comment is that setting the RNR t
I joined this list on time to see the discussion of the merge, so I'm
expecting the update, but thanks for the heads up. Until I saw the mail
about that, I hadn't realized the ORTE stuff was developed separately...now I
understand why the trunk version was left uncompilable so long :-).
What
On Feb 12, 2008, at 4:09 PM, ejon wrote:
I'll definitely plan an upgrade to the latest LSF release (7.0
update 2),
then. Given the roadmap, I think I'm way better off forging ahead
with MPI
on LSF than implementing a separate solution. I didn't really expect
production-ready code at this p
Thanks for response, Jeff.
I'll definitely plan an upgrade to the latest LSF release (7.0 update 2),
then. Given the roadmap, I think I'm way better off forging ahead with MPI
on LSF than implementing a separate solution. I didn't really expect
production-ready code at this point. Just chec
Hi Ralph -
How extensive are the changes involved in removing the GPR? How hard would
it be for someone to maintain an enhanced version of this as an addon or
compile-time optional module? Thanks.
- Doug
On Mon, 11 Feb 2008, Ralph Castain wrote:
> Hello all
>
> Per last week's telec
On Fri, Feb 01, 2008 at 11:40:20AM -0500, Tim Prins wrote:
> Adrian,
Hi!
Sorry for the late reply and thanks for your testing.
> 1. There are some warnings when compiling:
I've fixed these issues.
> 2. If I exclude all my tcp interfaces, the connection fails properly,
> but I do get a malloc
On Feb 12, 2008, at 7:11 AM, Lenny Verkhovsky wrote:
During coding new RMAPS component I found strange behavior of PLPA.
Same
behavior that was described in
http://www.open-mpi.org/community/lists/plpa-users/2007/04/0073.php
I believe that it was fixed in new version of PLPA.
This new versio
There are two issues:
- You must have a recent enough version of LSF. I'm afraid I don't
remember the LSF version number offhand, but we both (OMPI and LSF)
had to make some changes/fixes to achieve compatibility.
- LSF compatibility in OMPI is scheduled for v1.3 (i.e., it doesn't
exist
On Feb 11, 2008, at 7:33 PM, George Bosilca wrote:
But if you do all this internally in NewMadeleine, I guess you don't
need the Open MPI PML support.
s/PML/OB1/, since OB1 is the specific PML in Open MPI that does all
that stuff (striping, etc.).
:-)
--
Jeff Squyres
Cisco Systems
I just committed two patches to OMPI's ROMIO that I discussed this
morning on the teleconf. They remove two things from OMPI's bundled
ROMIO:
- function renaming (foo -> io_romio_foo)
- file sym linking (foo.c -> io_romio_foo.c)
Although these features were added for a good reason (to abide
Excellent; thanks!
Sometimes we have weird reasons for what we do, but there's
[usually :-)] a reason.
On Feb 12, 2008, at 1:00 PM, Shiqing Fan wrote:
Hi Jeff,
Sorry for that, I didn't know it before. Now it's fixed. Thanks a
lot. :)
Shiqing
Jeff Squyres wrote:
Why is memchecker.h
Hi Jeff,
Sorry for that, I didn't know it before. Now it's fixed. Thanks a lot. :)
Shiqing
Jeff Squyres wrote:
Why is memchecker.h included like this:
#include "ompi/include/ompi/memchecker.h"
Shouldn't it be
#include "ompi/memchecker.h"
Using the former will work in an SVN chec
Ew. I've filed a ticket:
https://svn.open-mpi.org/trac/ompi/ticket/1214
On Feb 12, 2008, at 11:27 AM, George Bosilca wrote:
I keep getting some warnings when I compile with gcc-4.2 on MAC OS X.
tools/compwrap/Makefile.am:38: `CXXFLAGS' is a user variable, you
should not override it;
Ralph --
We talked about this on the OMPI con call today and everyone agrees
that this seems to be a good plan. Just as a safety net: if the merge
goes disastrously wrong and you're unavailable Thu/Fri this week, we
can just back it out and try again later.
Thanks!
On Feb 11, 2008, at
I keep getting some warnings when I compile with gcc-4.2 on MAC OS X.
tools/compwrap/Makefile.am:38: `CXXFLAGS' is a user variable, you
should not override it;
tools/compwrap/Makefile.am:38: use `AM_CXXFLAGS' instead.
tools/compwrap/Makefile.am:40: `CPPFLAGS' is a user variable, you
should n
Why is memchecker.h included like this:
#include "ompi/include/ompi/memchecker.h"
Shouldn't it be
#include "ompi/memchecker.h"
Using the former will work in an SVN checkout, but won't work in a --
with-devel-headers installation (the latter should).
Can this be fixed?
--
Jeff Squyr
Developers --
When you add a new component, framework, or anything that includes one
or more new directories: please be sure to set the svn:ignore property
on each new directory properly. Here's the SVN docs on the svn:ignore
property:
http://svnbook.red-bean.com/en/1.4/svn-book.html#svn
autogen.sh has some deep mojo in it...
Would it be sufficient to just have our autogen.sh recurse down into
your tree? An undocumented feature of our autogen.sh is that you can
have a "autogen.subdirs" file in ompi/contrib/vt with a single line in
it: "vt". This will make our autogen recu
Ticket #1073 should be associated with the first bullet under "MCA
parameters" - "Scope & precedence cleanup"
It's unclear if this is "fixed" or not, but I had to look at this
ticket to determine what this bullet meant.
-- Josh
On Feb 11, 2008, at 10:09 PM, Brad Benton wrote:
All:
The l
I filed a ticket: https://svn.open-mpi.org/trac/ompi/ticket/1213
Am looking into the problem, but ran into the memchecker trunk build
breakage first (https://svn.open-mpi.org/trac/ompi/ticket/1211). #$%#@
%#@$%
On Feb 12, 2008, at 9:23 AM, Tim Prins wrote:
I just talked to Jeff abou
I just talked to Jeff about this. The problem was that on Sif we use
--enable-visibility, and apparently the new c++ bindings access
ompi_errhandler_create, which was not OMPI_DECLSPEC'd. Jeff will fix
this soon.
Tim
Jeff Squyres wrote:
I'm a little concerned about the C++ test build failures
Good points about 'distclean' versus 'clean'. For the make distclean
case then I think it is ok if we fail here since it is not a full
'make dist' that I was working with originally.
Sorry for the distraction.
Cheers,
Josh
On Feb 12, 2008, at 6:52 AM, Andreas Knüpfer wrote:
On Monday 11 F
To simplify things, I'm going to start filing tickets for all build
breaks that I find. Here's the latest:
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../opal/include -
I../../orte/include -I../../ompi/include -I../../opal/mca/paffinity/
linux/plpa/src/libplpa -I../.. -DOMPI_TV_DLL=\"/ho
I'm a little concerned about the C++ test build failures from last
night:
http://www.open-mpi.org/mtt/index.php?do_redir=530
They are likely due to the C++ changes that came in over the weekend,
but they *only* showed up at IU, which is somewhat odd. I'm trying to
replicate now (doing
In future all Makefile.in's and the configure script of VT will be built
from OMPI's autogen.sh.
I'm working on a solution, but the autogen.sh script is a little bit
unclear for me... :-(
Matthias
On Di, 2008-02-12 at 14:37 +0200, Gleb Natapov wrote:
> On Tue, Feb 12, 2008 at 01:08:32PM +0100,
On Tue, Feb 12, 2008 at 01:08:32PM +0100, Matthias Jurenz wrote:
> Hi Gleb,
>
> that's very strange... cause' the corresponding 'Makefile.in' is
> definitely not empty (checked in to the SVN repository).
Ah, here is the problem. Makefile.in is empty in my tree. I am building
not from SVN checkout,
The VampirTrace integration is already in the trunk. It should be mentioned as
complete somewhere in the misc section.
Andreas
signature.asc
Description: This is a digitally signed message part.
Hi all,
During coding new RMAPS component I found strange behavior of PLPA. Same
behavior that was described in
http://www.open-mpi.org/community/lists/plpa-users/2007/04/0073.php
I believe that it was fixed in new version of PLPA.
This new version needed to be merged to the trunk due to bug f
Hi Gleb,
that's very strange... cause' the corresponding 'Makefile.in' is
definitely not empty (checked in to the SVN repository).
Could you reproduce this error after 'make distclean, configure, make' ?
Which version of the autotools are you using?
Matthias
On Mo, 2008-02-11 at 11:42 +0200, Gl
On Monday 11 February 2008, Josh Hursey wrote:
> I've been noticing another problem with the VT integration. If you do
> a "./configure --enable-contrib-no-build=vt" a subsequent 'make
> distclean' will fail in contrib/vt. The 'make distclean' will succeed
> with VT enabled (default).
>
hm, tricky
Hi Ralf,
thanks for the patch. I've added this to the trunk...
Matthias
On Mo, 2008-02-11 at 21:14 +0100, Ralf Wildenhues wrote:
> Hello,
>
> please apply this patch, to make future contrib integration just a tad
> bit easier. I verified that the generated configure script is
> identical, mi
Hi,
I am planning to commit the following patch. Those two progress() calls
are responsible for most of our deep recursion troubles. And I also
think they are completely unnecessary.
diff --git a/ompi/mca/pml/ob1/pml_ob1_recvreq.c
b/ompi/mca/pml/ob1/pml_ob1_recvreq.c
index 5899243..641176e 10064
Hello Brad,
please note the valgrind memchecker merging, that could go in for 1.3
under the "m. Miscellaneous" section.
Also, please note, moving the ORTE merging to 1.3.1 would mean moving m.
Miscellaneous point vii., Windows CCP support there as well. The current/new
does not seem to work on w
38 matches
Mail list logo
