Re: [OMPI devel] oshmem test suite errors

I've got to keep working on my own features for v1.7.5, so > I need to move to other things right now. These start to sound like issues in the code; those last two are pretty decent tests. > I think I have oshmem running well enough to add these to Cisco's nightly MTT > runs now, so the re

Re: [OMPI devel] RFC: new OMPI RTE define:

l/mca/mca.h" > #include "opal/mca/base/base.h" > +#include "opal/mca/event/event.h" > > BEGIN_C_DECLS > > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > -- Brian Barrett There is an art . . . to flying. The knack lies in learning how to throw yourself at the ground and miss. Douglas Adams, 'The Hitchhikers Guide to the Galaxy'

Re: [OMPI devel] Updating the trunk

On Jun 30, 2009, at 5:57 PM, Ralph Castain wrote: If you are updating a prior checkout of the OMPI trunk with r21568, please be aware that there is an additional step required to make it build. Due to a quirk of the build system, you will need to do: rm ompi/tools/ompi_info/.deps/* and

Re: [OMPI devel] trac ticket 1944 and pending sends

Or go to what I proposed and USE A LINKED LIST! (as I said before, not an original idea, but one I think has merit) Then you don't have to size the fifo, because there isn't a fifo. Limit the number of send fragments any one proc can allocate and the only place memory can grow without

Re: [OMPI devel] CMR one-sided changes? (r21134)

Yeah, putting together a CMR is on the todo list :). Brian -- Brian Barrett There is an art . . . to flying. The knack lies in learning how to throw yourself at the ground and miss. On May 20, 2009, at 12:41, Jeff Squyres <jsquy...@cisco.com> wrote: Brian: can we CMR over yo

Re: [OMPI devel] RFC: Warn user about deprecated MPI functionality and "wrong" compiler usage

, to work around optimizer bugs. This is functionality I don't think should be lost just to warn about deprecated functions. Brian -- Brian Barrett There is an art . . . to flying. The knack lies in learning how to throw yourself at the ground and miss. On May 18, 2009, at 1:34, Rainer

Re: [OMPI devel] Revise paffinity method?

Jumping in late (travelling this morning). I think this is the right answer :). Brian -- Brian Barrett There is an art . . . to flying. The knack lies in learning how to throw yourself at the ground and miss. On May 8, 2009, at 9:45, Ralph Castain <r...@open-mpi.org> wrote: I think

Re: [OMPI devel] require newer autoconf?

I'd rather not. I have a couple of platforms with 2.59 installed, but not 2.60+. I really don't want to have to install my own autotools because of some bug that doesn't affect me. I don't, however, have a problem with forcing users to upgrade in order to get support for build-related

Re: [OMPI devel] RFC: Move of ompi_bitmap_t

ontje" <terry.don...@sun.com> wrote: I second Brian's concern. So unless this is just an announcement that this is being done on a tmp branch only until everything is in order I think we need further discussions. --td Brian Barrett wrote: So once again, I bring up my objection o

Re: [OMPI devel] RFC: Move of ompi_bitmap_t

ranch only until everything is in order I think we need further discussions. --td Brian Barrett wrote: So once again, I bring up my objection of this entire line of moving until such time as the entire process is properly mapped out. I believe it's premature to being moving around code

Re: [OMPI devel] RFC: Move of ompi_bitmap_t

...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Brian Barrett Open MPI developer http://www.open-mpi.org/

Re: [OMPI devel] RFC: sm Latency

I unfortunately don't have time to look in depth at the patch. But my concern is that currently (today, not at some made up time in the future, maybe), we use the BTLs for more than just MPI point-to- point. The rdma one-sided component (which was added for 1.3 and hopefully will be the

Re: [OMPI devel] 1.3 PML default choice

describe is the best compromise we manage to find few months ago. If you want to get the MX CM to run, you will have to clearly specify on the command line --mca pml cm. All other MTL will have the behavior described on the README. george. On Jan 13, 2009, at 20:18 , Brian Barrett wrote

Re: [OMPI devel] 1.3 PML default choice

On Jan 13, 2009, at 5:48 PM, Patrick Geoffray wrote: Jeff Squyres wrote: Gaah! I specifically asked Patrick and George about this and they said that the README text was fine. Grr... When I looked at that time, I vaguely remember that _both_ PMLs were initialized but CM was eventually

Re: [OMPI devel] Fwd: [OMPI users] Onesided + derived datatypes

function works correctly for the MPI_Send function, I don't see any reason not to do the same for the MPI_Put. As you're the one- sided guy in ompi, can you take a look at the MPI_Put to see why the data is incorrect? george. On Dec 11, 2008, at 19:14 , Brian Barrett wrote: I think that's

Re: [OMPI devel] Fwd: [OMPI users] Onesided + derived datatypes

george. On Dec 10, 2008, at 22:20 , Brian Barrett wrote: Hi all - I looked into this, and it appears to be datatype related. If the displacements are set t o 3, 2, 1, 0, there the datatype will fail the type checks for one-sided because is_overlapped() returns 1 for the datatype.

[OMPI devel] Fwd: [OMPI users] Onesided + derived datatypes

Hi all - I looked into this, and it appears to be datatype related. If the displacements are set t o 3, 2, 1, 0, there the datatype will fail the type checks for one-sided because is_overlapped() returns 1 for the datatype. My reading of the standard seems to indicate this should not

Re: [OMPI devel] memcpy MCA framework

I obviously won't be in Dublin (I'll be in a fishing boat in the middle of nowhere Canada -- much better), so I'm going to chime in now. The m4 part actually isn't too bad and is pretty simple. I'm not sure other than looking at some variables set by ompi_config_asm that there is much to

Re: [OMPI devel] if btl->add_procs() fails...?

On Aug 4, 2008, at 9:40 AM, Jeff Squyres wrote: On Aug 2, 2008, at 2:34 PM, Brian Barrett wrote: I am curious how all of the above affects client/server or spawned jobs. If you finalize a BTL then do a connect to a process that would use that BTL would it reinitialize itself? To deal

Re: [OMPI devel] if btl->add_procs() fails...?

My thought is that if add_procs fails, then that BTL should be removed (as if init failed) and things should continue on. If that BTL was the only way to reach another process, we'll catch that later and abort. There are always going to be errors that can't be detected until the device is

Re: [OMPI devel] Need v1.3 RM ruling (was: Help on building openmpi with "-Wl, --as-needed -Wl, --no-undefined")

ended up with Jeff's approach. Brian -- Brian Barrett There is an art . . . to flying. The knack lies in learning how to throw yourself at the ground and miss. On Jul 24, 2008, at 2:23, George Bosilca <bosi...@eecs.utk.edu> wrote: I tend to agree with Brian's comments, I would like

Re: [OMPI devel] Need v1.3 RM ruling (was: Help on building openmpi with "-Wl, --as-needed -Wl, --no-undefined")

nice features for the OS, which I don't totally understand. Because this problem will only become more common during the lifespan of 1.3.x , it makes sense to put this in v1.3, in my opinion. Brian -- Brian Barrett There is an art . . . to flying. The knack lies in learning how to throw

Re: [OMPI devel] Need v1.3 RM ruling (was: Help on building openmpi with "-Wl, --as-needed -Wl, --no-undefined")

Brian -- Brian Barrett There is an art . . . to flying. The knack lies in learning how to throw yourself at the ground and miss. On Jul 23, 2008, at 9:32, Jeff Squyres <jsquy...@cisco.com> wrote: Release managers: I have created ticket 1409 for this issue. I need a ruling: do yo

[OMPI devel] Two large patches in trunk

broke. Brian -- Brian Barrett There is an art . . . to flying. The knack lies in learning how to throw yourself at the ground and miss. Douglas Adams, 'The Hitchhikers Guide to the Galaxy'

Re: [OMPI devel] Memory hooks change testing

Did anyone get a chance to test (or think about testing) this? I'd like to commit the changes on Friday evening, if I haven't heard any negative feedback. Brian On Jun 9, 2008, at 8:56 PM, Brian Barrett wrote: Hi all - Per the RFC I sent out last week, I've implemented a revised

Re: [OMPI devel] Notes from mem hooks call today

-- Brian Barrett Open MPI developer http://www.open-mpi.org/

Re: [OMPI devel] undefined references forrdma_get_peer_addr & rdma_get_local_addr

trunk5/config-data1/orte/.libs/libopen- >>>> rte.so /share/home/00951/paklui/ompi-trunk5/config-data1/ >>>> opal/.libs/ libopen-pal.so -lnuma -ldl -lnsl -lutil -lpthread - >>>> Wl,--rpath -Wl,/ share/home/00951/paklui/ompi-trunk5/shared- >>>> install1/lib >>>> >>>> [1]Exit 2make install >& >>>> make.install.log.0 >>>> ../../../ompi/.libs/libmpi.so: undefined reference to >>>> `rdma_get_peer_addr' >>>> ../../../ompi/.libs/libmpi.so: undefined reference to >>>> `rdma_get_local_addr' >>>> make[2]: *** [ompi_info] Error 2 >>>> make[2]: Leaving directory `/share/home/00951/paklui/ompi-trunk5/ >>>> config-data1/ompi/tools/ompi_info' >>>> make[1]: *** [install-recursive] Error 1 >>>> make[1]: Leaving directory `/share/home/00951/paklui/ompi-trunk5/ >>>> config-data1/ompi' >>>> make: *** [install-recursive] Error 1 >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> - Pak Lui >>>> pak@sun.com >> >> -- >> >> >> - Pak Lui >> pak@sun.com >> > > -- - Pak Lui pak@sun.com ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Brian Barrett Open MPI developer http://www.open-mpi.org/

Re: [OMPI devel] FreeBSD timer_base_open error?

it should probably be modified to check both for that file (there are systems that call themselves "linux" but don't have a /proc/cpuinfo) is readable and that we're actually on Linux. Brian -- Brian Barrett There is an art . . . to flying. The knack lies in learning how

Re: [OMPI devel] [RFC] Non-blocking collectives (LibNBC) merge to trunk

them to rewrite their applications. Just my $0.02, Brian -- Brian Barrett Open MPI developer http://www.open-mpi.org/

Re: [OMPI devel] SDP support for OPEN-MPI

/ +#endif /* OAP_WANT_SDP */ opal_mutex_t tcp_lock; /**< lock for accessing module state */ opal_list_ttcp_events; /**< list of pending events (accepts) */ opal_list_ttcp_msg_post; /**< list of recieves user has posted */ Thanks, Verkhovsky Lenny. ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Brian Barrett Open MPI developer http://www.open-mpi.org/

Re: [OMPI devel] collective problems

As it stands today, the problem is that we can inject things into the BTL successfully that are not injected into the NIC (due to software flow control). Once a message is injected into the BTL, the PML marks completion on the MPI request. If it was a blocking send that got marked as

Re: [OMPI devel] bml_btl->btl_alloc() instead of mca_bml_base_alloc() in OSC

Can't think of any good reason -- the patch should be fine. Thanks, Brian On Oct 28, 2007, at 7:13 AM, Gleb Natapov wrote: Hi Brian, Is there a special reason why you call btl functions directly instead of using bml wrappers? What about applying this patch? diff --git

Re: [OMPI devel] problem in runing MPI job through XGrid

XGrid does not forward X11 credentials, so you would have to setup an X11 environment by yourself. Using ssh or a local starter does forward X11 credentials, which is why it works in that case. Brian On Oct 25, 2007, at 10:23 PM, Jinhui Qin wrote: Hi Brian, I got another problem in

Re: [OMPI devel] PML cm and heterogeneous support

No, it's because the CM PML was never designed to be used in a heterogeneous environment :). While the MX BTL does support heterogeneous operations (at one point, I believe I even had it working), none of the MTLs have ever been tested in heterogeneous environments and it's known the

Re: [OMPI devel] PathScale 3.0 problems with Open MPI 1.2.[34]

On Oct 23, 2007, at 10:58 AM, Patrick Geoffray wrote: Bogdan Costescu wrote: I made some progress: if I configure with "--without-memory-manager" (along with all other options that I mentioned before), then it works. This was inspired by the fact that the segmentation fault occured in

Re: [OMPI devel] RFC: versioning OMPI libraries

it or not (and whether the RM's will take on the responsibility of gathering this data for each release). On Oct 15, 2007, at 1:16 PM, Christian Bell wrote: On Mon, 15 Oct 2007, Brian Barrett wrote: No! :) It would be good for everyone to read the Libtool documentation to see why versioning

Re: [OMPI devel] RFC: versioning OMPI libraries

No! :) It would be good for everyone to read the Libtool documentation to see why versioning on the release number would be a really bad idea. Then comment. But my opinion would be that you should change based on interface changes, not based on release numbers. Brian On Oct 15,

Re: [OMPI devel] problem in runing MPI job through XGrid

On Oct 4, 2007, at 3:06 PM, Jinhui Qin wrote: sib:sharcnet$ mpirun -n 3 ~/openMPI_stuff/Hello Process 0.1.1 is unable to reach 0.1.2 for MPI communication. If you specified the use of a BTL component, you may have forgotten a component (such as "self") in the list of usable components. This

Re: [OMPI devel] OpenIB component static compile failures

By the way, I filed a bug on this issue: https://svn.open-mpi.org/trac/ompi/ticket/1155 Brian On Oct 2, 2007, at 8:57 AM, Brian Barrett wrote: No, actually, my report isn't about that issue at all. I'm not talking about making an entirely statically built application. I'm talking

Re: [OMPI devel] OpenIB component static compile failures

e to file a ticket and fix if you'd like... On Oct 1, 2007, at 11:56 PM, Brian Barrett wrote: Hi all - There's a problem with the OpenIB components when statically linking. For whatever reason, the configure logic is not adding the right -L and -l flags to the mpicc wrapper flags. [17:26]

[OMPI devel] OpenIB component static compile failures

Hi all - There's a problem with the OpenIB components when statically linking. For whatever reason, the configure logic is not adding the right -L and -l flags to the mpicc wrapper flags. [17:26] brbarret@odin:pts/8 examples> mpicc -showme gcc

Re: [OMPI devel] Malloc segfaulting?

On Sep 20, 2007, at 7:02 AM, Tim Prins wrote: In our nightly runs with the trunk I have started seeing cases where we appear to be segfaulting within/below malloc. Below is a typical output. Note that this appears to only happen on the trunk, when we use openib, and are in 32 bit mode.

Re: [OMPI devel] FreeBSD Support?

On Sep 19, 2007, at 4:11 PM, Tim Prins wrote: Here is where it gets nasty. On FreeBSD, /usr/include/string.h includes strings.h in some cases. But there is a strings.h in the ompi/mpi/f77 directory, so that is getting included instead of the proper /usr/include/strings.h. I suppose we could

Re: [OMPI devel] Maximum Shared Memory Segment - OK to increase?

On Aug 28, 2007, at 9:05 AM, Li-Ta Lo wrote: On Mon, 2007-08-27 at 15:10 -0400, Rolf vandeVaart wrote: We are running into a problem when running on one of our larger SMPs using the latest Open MPI v1.2 branch. We are trying to run a job with np=128 within a single node. We are seeing the

Re: [OMPI devel] ompi_mpi_abort

On Aug 25, 2007, at 7:10 AM, Jeff Squyres wrote: 1. We have logic in ompi_mpi_abort to prevent recursive invocation (ompi_mpi_abort.c:60): /* Protection for recursive invocation */ if (have_been_invoked) { return OMPI_SUCCESS; } have_been_invoked = true; This,

Re: [OMPI devel] [devel-core] [RFC] Runtime Services Layer

On Aug 24, 2007, at 9:08 AM, George Bosilca wrote: By heterogeneous RTE I was talking about what will happened once we have the RSL. Different back-end will support different features, so from the user perspective we will not provide a homogeneous execution environment in all situations. On the

Re: [OMPI devel] Question on NX bit patch in Debian

You are correct -- we now add a .note.GNU-stack to the assembly file if the assembler supports it, so that patch should no longer be needed. Brian On Aug 18, 2007, at 9:03 AM, Manuel Prinz wrote: Hi everyone, in the Debian package of OpenMPI there has been a patch [1] for some time which I

Re: [OMPI devel] [OMPI svn] svn:open-mpi r15903

Fixed. Sorry about the configure change mid-day, but it seemed like the right thing to do. Brian On Aug 17, 2007, at 10:37 AM, Brian Barrett wrote: Oh, crud. I forgot to fix that issue. Will fix asap. Brian On Aug 17, 2007, at 10:12 AM, George Bosilca wrote: This patch break

Re: [OMPI devel] [OMPI svn] svn:open-mpi r15903

Oh, crud. I forgot to fix that issue. Will fix asap. Brian On Aug 17, 2007, at 10:12 AM, George Bosilca wrote: This patch break the trunk. It looks like the LT_PACKAGE_VERSION wasn't defined before the 2.x version. The autogen fails with the following error: *** Running GNU tools [Running]

Re: [OMPI devel] openib btl header caching

On Aug 13, 2007, at 9:33 AM, George Bosilca wrote: On Aug 13, 2007, at 11:28 AM, Pavel Shamis (Pasha) wrote: Jeff Squyres wrote: I guess reading the graph that Pasha sent is difficult; Pasha -- can you send the actual numbers? Ok here is the numbers on my machines: 0 bytes mvapich with

[OMPI devel] Collectives interface change

Hi all - There was significant discussion this week at the collectives meeting about improving the selection logic for collective components. While we'd like the automated collectives selection logic laid out in the Collv2 document, it was decided that as a first step, we would allow

Re: [OMPI devel] Startup failure on mixed IPv4/IPv6 environment (oob tcp bug?)

On Aug 5, 2007, at 3:05 PM, dispan...@sobel.ls.la wrote: I fixed the problem by setting the peer_state to MCA_OOB_TCP_CONNECTING after creating the socket, which works for me. I'm not sure if this is always correct, though. Can you try the attached patch? It's pretty close to what

Re: [OMPI devel] MPI_Win_get_group

On Jul 28, 2007, at 6:27 AM, Jeff Squyres wrote: On Jul 27, 2007, at 8:27 PM, Lisandro Dalcin wrote: MPI_WIN_GET_GROUP returns a duplicate of the group of the communicator used to create the window. associated with win. The group is returned in group. Well, it seems OMPI (v1.2 svn) is not

Re: [OMPI devel] [RFC] Sparse group implementation

On Jul 26, 2007, at 1:01 PM, Mohamad Chaarawi wrote: On Thu, July 26, 2007 1:18 pm, Brian Barrett wrote: On Jul 26, 2007, at 12:00 PM, Mohamad Chaarawi wrote: 2) I think it would be better to always have the flags and macros available (like OMPI_GROUP_SPORADIC and OMPI_GROUP_IS_SPORADIC

Re: [OMPI devel] [RFC] Sparse group implementation

On Jul 26, 2007, at 12:00 PM, Mohamad Chaarawi wrote: 2) I think it would be better to always have the flags and macros available (like OMPI_GROUP_SPORADIC and OMPI_GROUP_IS_SPORADIC) even when sparse groups are disabled. They dont' take up any space, and mean less #ifs in the general code

Re: [OMPI devel] [RFC] Sparse group implementation

the number of #ifs in the code to only 2 (as i recall that i had it before) .. Thank you, Mohamad On Wed, July 25, 2007 4:23 pm, Brian Barrett wrote: On Jul 25, 2007, at 3:14 PM, Jeff Squyres wrote: On Jul 25, 2007, at 5:07 PM, Brian Barrett wrote: It just adds a lot of #if's throughout the code

Re: [OMPI devel] [RFC] Sparse group implementation

On Jul 25, 2007, at 3:14 PM, Jeff Squyres wrote: On Jul 25, 2007, at 5:07 PM, Brian Barrett wrote: It just adds a lot of #if's throughout the code. Other than that, there's no reason to remove it. I agree, lots of #ifs are bad. But I guess I don't see the problem. The only real important

Re: [OMPI devel] [RFC] Sparse group implementation

On Jul 25, 2007, at 2:56 PM, Jeff Squyres wrote: On Jul 25, 2007, at 10:39 AM, Brian Barrett wrote: I have an even bigger objection than Rich. It's near impossible to measure the latency impact of something like this, but it does have an additive effect. It doesn't make sense to have all

Re: [OMPI devel] [RFC] Sparse group implementation

I have an even bigger objection than Rich. It's near impossible to measure the latency impact of something like this, but it does have an additive effect. It doesn't make sense to have all that code in the critical path for systems where it's not needed. We should leave the compile time

Re: [OMPI devel] Fwd: [Open MPI] #1101: MPI_ALLOC_MEM with 0 size must be valid

On Jul 24, 2007, at 8:28 AM, Gleb Natapov wrote: On Tue, Jul 24, 2007 at 11:20:11AM -0300, Lisandro Dalcin wrote: On 7/23/07, Jeff Squyres wrote: Does anyone have any opinions on this? If not, I'll go implement option #1. Sorry, Jeff... just reading this. I think your

Re: [OMPI devel] [OMPI svn] svn:open-mpi r15492

Sigh. Thanks. Should probably have tested that code ;). And the solaris code. and the windows code. Brian On Jul 19, 2007, at 7:37 AM, Jeff Squyres wrote: Thanks! Ralph got it this morning in https://svn.open-mpi.org/trac/ompi/ changeset/15501. On Jul 19, 2007, at 5:34 AM, Bert

[OMPI devel] RML/OOB change heads up

Hey all - Thought I would give you guys a heads up on some code that will be coming into the trunk in the not too distant future (hopefully tomorrow?). The changes revolve around the RML/OOB interface and include: * General TCP cleanup for OPAL / ORTE * Simplifying the OOB by moving

Re: [OMPI devel] Build failures of 1.2.3 on Debian hppa, mips, mipsel, s390, m68k

(completely or partially?) Anybody knows about any other components with atomic requirements ? george. On Jul 14, 2007, at 1:59 PM, Brian Barrett wrote: On Jul 14, 2007, at 11:51 AM, Gleb Natapov wrote: On Sat, Jul 14, 2007 at 01:16:42PM -0400, George Bosilca wrote: Instead of failing

Re: [OMPI devel] Build failures of 1.2.3 on Debian hppa, mips, mipsel, s390, m68k

On Jul 14, 2007, at 11:51 AM, Gleb Natapov wrote: On Sat, Jul 14, 2007 at 01:16:42PM -0400, George Bosilca wrote: Instead of failing at configure time, we might want to disable the threading features and the shared memory device if we detect that we don't have support for atomics on a

Re: [OMPI devel] Build failures of 1.2.3 on Debian hppa, mips, mipsel, s390, m68k

On Jul 14, 2007, at 10:53 AM, Dirk Eddelbuettel wrote: Methinks we need to fill in a few blanks here, or make do with non-asm solutions. I don't know the problem space that well (being a maintainer rather than upstream developer) and am looking for guidance. Either way is an option. There

Re: [OMPI devel] Build failures of 1.2.3 on Debian hppa, mips, mipsel, s390, m68k

On Jul 14, 2007, at 8:26 AM, Dirk Eddelbuettel wrote: Please let us (ie Debian's openmpi maintainers) how else we can help. I am ccing the porters lists (for hppa, m68k, mips) too to invite them to help. I hope that doesn't get the spam filters going... I may contact the 'arm' porters

Re: [OMPI devel] Notes on building and running Open MPI on Red Storm

Do you have a Subversion account? If so, feel free to update the wiki ;). If not, we should probably get you an account. Then feel free to update the wiki ;). But thanks for the notes! Brian On Jul 11, 2007, at 4:47 PM, Glendenning, Lisa wrote: Some supplementary information to the

Re: [OMPI devel] Multi-environment builds

On Jul 10, 2007, at 7:09 AM, Tim Prins wrote: Jeff Squyres wrote: 2. The "--enable-mca-no-build" option takes a comma-delimited list of components that will then not be built. Granted, this option isn't exactly intuitive, but it was the best that we could think of at the time to present a

[OMPI devel] fake rdma flag again?

Hi all - I've finally committed a version of the rdma one-sided component that 1) works and 2) in certain situations actually does rdma. I'll make it the default when the BTLs are used as soon as one last bug is fixed in the DDT engine. However, there is still one outstanding issue.

Re: [OMPI devel] One-sided operations with Portals

On Jul 5, 2007, at 4:16 PM, Glendenning, Lisa wrote: Ron Brightwell at SNL has asked me to look into optimizing Open MPI's one-sided operations over Portals. Does anyone have any guidance or thoughts for this? Hi Lisa - There are currently two implementations of the one-sided interface

Re: [OMPI devel] Modex

as long as we can have some sort of documenation describing what changed like which old functions are replaced with newer functions and any description of changed assumptions. --td Brian Barrett wrote: On Jun 26, 2007, at 6:08 PM, Tim Prins wrote: Some time ago you were working on moving

Re: [OMPI devel] Modex

On Jun 26, 2007, at 6:08 PM, Tim Prins wrote: Some time ago you were working on moving the modex out of the pml and cleaning it up a bit. Is this work still ongoing? The reason I ask is that I am currently working on integrating the RSL, and would rather build on the new code rather than

Re: [OMPI devel] Patch to fix cross-compile failure

Argonne used AC_TRY_RUN instead of AC_TRY_COMPILE (I believe) because there are some places where aio functions behaved badly (returned ENOTIMPL or something). I was going to make it call AC_TRY_RUN if we weren't cross-compiling and AC_TRY_COMPILE if we were. I'll commit something this

Re: [OMPI devel] [OMPI svn] svn:open-mpi r14768

I'm available this afternoon... Brian On Jun 7, 2007, at 12:39 PM, George Bosilca wrote: I'm available this afternoon. george. On Jun 7, 2007, at 2:35 PM, Galen Shipman wrote: Are people available today to discuss this over the phone? - Galen On Jun 7, 2007, at 11:28 AM, Gleb

Re: [OMPI devel] [OMPI svn] svn:open-mpi r14897

Yup, thanks. Brian On Jun 6, 2007, at 2:27 AM, Bert Wesarg wrote: +#ifdef HAVE_REGEXEC +args_count = opal_argv_count(options_data[i].compiler_args); +for (j = 0 ; j < args_count ; ++j) { +if (0 != regcomp(, options_data[i].compiler_args [j], REG_NOSUB)) { +

Re: [OMPI devel] undefined environ symbol on Darwin

On May 29, 2007, at 7:35 AM, Jack Howarth wrote: and if you see environ undefined, identify which library it is in and which object file it came from. I would also note that my patch reveals that several instances of the environ variable being declared that are missing the Windows wrappers. So

Re: [OMPI devel] undefined environ symbol on Darwin

On May 28, 2007, at 4:57 PM, Jack Howarth wrote: I have been told that Paraview is one package that exhibits this problem with undefined environ symbols. This will occur in any package which creates its own shared libraries that link in any openmpi shared library that contains the undefined

Re: [OMPI devel] [RFC] Send data from the end of a buffer during pipeline proto

On the other hand, since the MPI standard explicitly says you're not allowed to call fork() or system() during the MPI application and sense the network should really cope with this in some way, if it further complicates the code *at all*, I'm strongly against it. Especially since it

[OMPI devel] Autotools Upgrade Time

Hi all - As was discussed on the telecon a couple of weeks ago, to try to lower the maintenance cost of the build system, starting this Saturday Autoconf 2.60 and Automake 1.10 will be required to successfully run autogen.sh on the trunk. As I mentioned in a previous e-mail, the

Re: [OMPI devel] Fancy ORTE/MPIRUN bugs

On Apr 19, 2007, at 8:38 AM, Aurelien Bouteiller wrote: Hi, I am experiencing several fancy bugs with ORTE. All bugs occur on Intel 32 bits architecture under Mac OS X using gcc 4.2. The tested version is todays trunk (it also have occured for at least three weeks) First occurs when compiling

Re: [OMPI devel] SOS!! Run-time error

Wow, it appears everything aborts when opal_event_loop() is called. Did you make any changes to the event library code in opal/event/? If not, that might indicate a mismatch between the binaries and libraries (ie, binaries from one build vs. libraries from another). This will cause

Re: [OMPI devel] Is it possible to get BTL transport work directly with MPI level

On Apr 2, 2007, at 10:23 AM, Jeff Squyres wrote: On Apr 1, 2007, at 3:12 PM, Ralph Castain wrote: I can't help you with the BTL question. On the others: 2. Go through the BML instead -- the BTL Management Layer. This is essentially a multiplexor for all the BTLs that have been

Re: [OMPI devel] comment on wiki/PrintfCodes

On Feb 26, 2007, at 1:54 PM, Bert Wesarg wrote: I can only speak for a 3 year old linux system but I read evenly the wiki page https://svn.open-mpi.org/trac/ompi/wiki/PrintfCodes and I wonder if someone tried this code. On my system the PRId32 is defined as "d" for example. so to use this

Re: [OMPI devel] [PATCH] ompi_get_libtool_linker_flags.m4: fix $extra_ldflags detection

Very true, thanks. I'll fix this evening. Brian On Feb 25, 2007, at 4:51 AM, Bert Wesarg wrote: Hallo, ok the sed should be even more portable. but the problem with a CC like "gcc -m32" isn't solved, so you should add this line and use the $tmpCC in the sed expression, to get "gcc

Re: [OMPI devel] installed wrappers

On Feb 15, 2007, at 2:54 AM, Bert Wesarg wrote: why are the mpiCC, mpif77, and mpif90 wrappers installed, when i specify --disable-mpi-cxx, --disable-mpi-f77, and --disable-mpi-f90 for the ./configure? The Fortran 77 and Fortran 90 compilers will be disabled and return an error if those

Re: [OMPI devel] build problem with 1.1.4

On Feb 15, 2007, at 3:07 AM, Bert Wesarg wrote: I encounter a build problem with openmpi 1.1.4, which don't show up with version 1.1.2. After a simple ./configure, the variable OPAL_DATADIR in opal/include/opal/install_dirs.h shows this: $ grep '^#define OPAL_DATADIR'

[OMPI devel] (no subject)

to activate the multi-lib support in the wrapper compilers. Comments? Brian -- Brian Barrett Open MPI developer http://www.open-mpi.org/

[OMPI devel] configure changes (ooops!)

Hi all - At the last minute last night I wanted to change one small detail in the wrapper compiler code. Then, as is typical with me, I got distracted. As some of you noticed, none of the configure changes made it into the trunk last night. Should happen this weekend. Sorry about

Re: [OMPI devel] Buffer Overflow Error

What facilities are you using to detect the buffer overflow? We've seen no such issues in our testing and I'd be surprised if there was an issue in that code path. Valgrind and friends don't show any issues on our test machines, so without more detail, I'm afraid we really can't fix the issue

Re: [OMPI devel] Stack trace printing

Yes. It's always the trampoline, the signal handler, and the stack trace printer. Brian On Wed, 2006-08-30 at 17:37 -0400, Jeff Squyres wrote: > As long as it's always 3 function calls -- do we know that it will be? > > > On 8/30/06 5:32 PM, "Brian Barrett" <brb

[OMPI devel] Stack trace printing

Hi all- A question about stack tracing. Currently, we have it setup so that, say, a segfault results in: [0]func:/u/jjhursey/local/odin/ompi/devel/lib/libopal.so.0(opal_backtrace_print+0x2b) [0x2a959166ab] [1] func:/u/jjhursey/local/odin/ompi/devel/lib/libopal.so.0 [0x2a959150bb] [2]

Re: [OMPI devel] OpenRTE and Threads

In general, I think making the Public interface to OpenRTE not thread safe is a reasonable thing to do. However, I have some concern over how this would work with the event library. When the project is compiled with progress threads, the event library runs in its own thread. More important to

[OMPI devel] LANL ORTE todo / milestones

Hi all - LANL had an internal meeting yesterday trying to classify a number of issues we're having with the run-time environment for Open MPI and how to best prioritize team resources. We thought it would be good to both share the list (with priorities) with the group and to ask the group if

Re: [OMPI devel] exit declaration in configure tests

On Mon, 2006-08-21 at 09:38 +0200, Ralf Wildenhues wrote: > Revision 11268 makes me curious: > > |M /trunk/config/ompi_setup_cxx.m4 > | > | Reorder the C++ compiler discovery stages. Check first the compiler vendor > | before checking if we are able to compile the test program. This is

Re: [OMPI devel] one-sided communication implementation

On Thu, 2006-07-20 at 11:56 +1000, gh rory wrote: > In the process of trying to create a wrapper for open mpi to another > language. Specifically, I am trying to understand how the remote > memory access/one-sided communication works in open mpi 1.1, and I am > having some trouble. > > I have

[OMPI devel] trunk changes: F90 shared libraries / New one-sided component

Hi all - Two large changes to the SVN trunk just occurred which require an autogen.sh on your part. First, we now (mostly) support building the Fortran 90 MPI bindings library as a shared library. This has been something Dan and I have been working on since the Burlington meeting, and it's

Re: [OMPI devel] progress thread check

On Thu, 2006-07-27 at 07:49 -0400, Graham E Fagg wrote: > Hi all > is there a single function call that components can use to check that the > progress thread is up and running ? Not really. But if the define OMPI_ENABLE_PROGRESS_THREADS is 1 and opal_using_threads() returns true, then it can

Re: [OMPI devel] universal / "fat" binary support?

On Thu, 2006-07-27 at 15:21 -0700, Ben Byer wrote: > I'd like to be able to build OpenMPI "fat" -- for multiple > architectures in one pass, so I can create a universal binary for > OSX. I see that it was mentioned last year, at http://www.open- >

[OMPI devel] SVN breakage / new event library committed

Hi all - I just finished committing the event library into the trunk. Unfortunately, because the event library was not imported using a vendor import 2 years ago, I had to do some things that made SVN a little unhappy. The good news is that the next libevent update will not require

Re: [OMPI devel] Problem compiling openmpi 1.1

On Mon, 2006-07-10 at 17:44 +0200, Pierre wrote: > rtsig.c:365: error: `EV_SIGNAL' undeclared (first use in this function) > rtsig.c:392: error: dereferencing pointer to incomplete type > rtsig.c:392: error: `EV_PERSIST' undeclared (first use in this function) > make[3]: *** [rtsig.lo] Error 1 >

  1   2   >