Chock full of fixes:
http://www.open-mpi.org/software/ompi/v1.4/
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
ompiled out, there is no reason to complain.
>
> george.
>
> On Sep 6, 2011, at 17:36 , Jeff Squyres wrote:
>
>> Don't forget that this RFC has a timeout of today. I didn't think it would
>> be controversial, which is why it had a short timeout.
>>
librdmacm.
> Please correct me if I am wrong.
It can use librdmacm, but it doesn't have to (and doesn't by default).
librdmacm uses its own internal communications -- I'm not sure what transport
layer it uses. By default, however, OMPI uses a TCP-based connection mechani
; distribution
>> is prohibited. If you are not the intended recipient, please contact the
>> sender by
>> reply email and destroy all copies of the original message.
>> ---
>>
>> ___
>> 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
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
You
can enable them via --enable-hwloc-xml, which will also turn on additional
machinery in ORTE to send node topology info back to the HNP for accurate
process mapping (more on this coming soon).
On Aug 31, 2011, at 3:05 PM, Jeff Squyres wrote:
> WHAT: Move hwloc up to be a first-class
On Sep 12, 2011, at 8:51 AM, Jeff Squyres wrote:
> *** Remember that although the opal_hwloc_topology global variable will
> always be available, ##IT MAY BE NULL## on platforms where hwloc was compiled
> out / not supported. Therefore, you MUST protect access to hwloc API calls
&
existence of one macro."
>
> Is the objective to test for the existence of the macro, its value, or its
> value IFF it exists?
>
> Ken Lloyd
>
> -Original Message-
> From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On
> Behalf Of Jeff Squyres
>
it to its local processes during the ESS handshake.
To be specific:
- the orted and HNP will have non-NULL values in opal_hwloc_topology after the
ESS startup
- MPI processes will have non-NULL values of opal_hwloc_topology after
orte_init()
--
Jeff Squyres
jsquy...@cisco.com
For corporate
TIPC native primitive for broadcast that you want to
use? If so, you could write a tipc coll component that has just the bcast
method (and NULL for everything else).
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
In the usual place:
http://www.open-mpi.org/software/ompi/v1.4/
Please test!
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
__
>> De : devel-boun...@open-mpi.org [devel-boun...@open-mpi.org] de la part de
>> George Bosilca [bosi...@eecs.utk.edu]
>> Date d'envoi : 27 septembre 2011 16:44
>> À : Open MPI Developers
>> Objet : Re: [OMPI devel] RE : Implementation of MPI_Iprobe
>>
>> Sebastien,
>>
>> Please try the attached patch. It is made against the trunk, so you might
>> have to adapt it slightly.
>>
>> Let me know of the outcome, so we can decide if it's worth pushing it in the
>> next releases.
>>
>> Thanks,
>> george.
>>
>>
>
>
>
>
> Sébastien___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
. My point is that there are a bunch of different options you can pursue
outside of the "everyone sends to 1 master" model.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
- SEE THE SLURM LICENSE FOR
> INFO])
> + orte_enable_pmi=1] [$2],[
> + AC_MSG_RESULT([no])
> + AC_MSG_WARN([PMI support requested (via --with-pmi) but
> not found.])
> + AC_MSG_ERROR([Aborting.])] [$3])])
> + AC_DEFINE_UNQUOTED([W
tantly, we should remove that particular warning from this
> test, since the test is used in places other than SLURM, which don't have
> negative licensing impact.
Fair enough; is there a way to tell the difference between BSD-friendly PMI and
not-BSD-friendly PMI?
> Brian
>
_
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
icted to supporting communication over
> sockets and shared memory. In an effort to support a wider range of networks
> (e.g., InfiniBand, Myrinet), they have created a CRS component to hook into
> Open MPI's checkpoint/restart infrastructure. The MTCP user-level
> checkpoi
assume it will work. Maybe someone still using
> 2.5.4 can validate this.
>
> -- Swen
>
> On Oct 6, 2011, at 2:59 PM, Jeff Squyres wrote:
>
>> Nifty -- I had no idea that %unput existed. Do you know how far back it
>> works in flex versions? We currently say
at:
>>>>
>>>> https://bitbucket.org/jsquyres/ompi-dmtcp2
>>>>
>>>> The DMTCP parent project website is below:
>>>>
>>>> http://dmtcp.sourceforge.net/
>>>>
>>>> The Distributed MultiThreaded Check
component
>>>>> for Open MPI.
>>>>>
>>>>> ---
>>>>> More details:
>>>>>
>>>>> Open MPI MTCP integration implementation available at:
>>>>>
>>
#x27;t tell the difference. End result: it *looks* like
the "From a network..." paragraph is quoted from another message, but it's
actually not. It's just a quirk in how internet mail works.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Good enough. Thanks!
On Oct 11, 2011, at 9:42 AM, Boehm, Swen wrote:
> I know for sure that it works with 2.5.35 but I am confident that it will
> work with 2.5.33.
> I committed the changes to trunk.
>
> -- Swen
>
> On Oct 6, 2011, at 5:48 PM, Jeff Squyres wrote:
>
d, ORTE_ERROR_NAME(rc));
> +opal_output(0, "Debugger_attach[rank=%ld]: could not wait for
> debugger!",
> +(long)ORTE_PROC_MY_NAME->vpid);
> }
> }
> #endif
> _______
> svn-full
* btl is no longer available
> */
>
> Modified: trunk/ompi/mpiext/cr/c/quiesce_start.c
> ======
> --- trunk/ompi/mpiext/cr/c/quiesce_start.c(original)
> +++ trunk/ompi/mpiext/cr/c/quiesce_start.c2011-10-18 23:51:53 EDT (Tue,
> 18 Oct 2011)
> @@ -2,6 +2,9 @@
> * Copyright (c) 2004-2010 The Trustees of Indiana University and Indiana
> * University Research and Technology
> * Corporation. All rights reserved.
> + * Copyright (c) 2011 The University of Tennessee and The University
> + * of Tennessee Research Foundation. All rights
> + * reserved.
> * $COPYRIGHT$
> *
> * Additional copyrights may follow
> @@ -205,6 +208,6 @@
> info_char = NULL;
> }
>
> -return ORTE_SUCCESS;
> +return OMPI_SUCCESS;
> }
> #endif
> ___
> svn-full mailing list
> svn-f...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/svn-full
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
6.233/bin/intel64:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/java/latest/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/opt/eclipse:/opt/ganglia/bin:/opt/ganglia/sbin:/opt/maui/bin:/opt/torque/bin:/opt/torque/sbin:/opt/rocks/bin:/opt/rocks/sbin:/root/bin
>>>>>>>
>>>>>>> Here's the steps I use to make and test OpenMPI 1.4.3 (I use a patched
>>>>>>> version to accommodate the six compilers we have; I've submitted those
>>>>>>> patches here in the past):
>>>>>>>
>>>>>>>> # cd /usr/local/src
>>>>>>>> # tar -xjf openmpi-1.4.3-patched.tar.bz2
>>>>>>>> # cd openmpi-1.4.3
>>>>>>>> # module load compilers/intel/2011.6.233
>>>>>>>> # ./configure >../openmpi-1.4.3-configure-intel.6.233.log 2>&1
>>>>>>>> --with-tm --with-openib --without-valgrind --without-udapl
>>>>>>>> --enable-contrib-no-build=vt --with-wrapper-ldflags="-shared-intel"
>>>>>>>> CC="icc" CFLAGS="-g -O3" CXX="icpc" CXXFLAGS="-g -O3" FC="ifort"
>>>>>>>> FCFLAGS="-g -O3" F77="ifort" FFLAGS="-g -O3" LDFLAGS="-shared-intel"
>>>>>>>> # make >../openmpi-1.4.3-make-intel.6.233.log 2>&1
>>>>>>>> # make check >../openmpi-1.4.3-check-intel.6.233.log 2>&1
>>>>>>>
>>>>>>> (When I generate the OpenMPI 1.4.3 library we actually use, I also add
>>>>>>> a --prefix. But, that complicates diff's of the stdout files for these
>>>>>>> steps, so it is not used here. Thus, I do NOT proceed to make install
>>>>>>> any of these libraries.)
>>>>>>>
>>>>>>> The three earlier versions of the Intel 2011 compilers all pass the
>>>>>>> make check tests. When I compare the ./configure stdout files, they
>>>>>>> are all identical. However, the ./configure stdout file for the Intel
>>>>>>> 2011.6.233 compilers has one difference:
>>>>>>>
>>>>>>>> [root@hydra openmpi-1.4.3]# diff
>>>>>>>> ../openmpi-1.4.3-configure-intel.{5.220,6.233}.log
>>>>>>>> 178c178
>>>>>>>> < checking for __attribute__(may_alias)... no
>>>>>>>> ---
>>>>>>>> > checking for __attribute__(may_alias)... yes
>>>>>>>
>>>>>>> That is obviously where I will start looking for the source of the
>>>>>>> problem.
>>>>>>>
>>>>>>> Maybe someone reading this list knows what the purpose of that test is,
>>>>>>> whether the Intel 2011 compilers are expected to have this feature
>>>>>>> enabled, and whether the code this enables can cause this problem if
>>>>>>> the Intel 2011.6.233 compilers do not fully support whatever this test
>>>>>>> is intended to discern.
>>>>>>>
>>>>>>> Larry Baker
>>>>>>> US Geological Survey
>>>>>>> 650-329-5608
>>>>>>> ba...@usgs.gov
>>>>>>>
>>>>>>> ___
>>>>>>> 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
>>>>>
>>>>> ___
>>>>> 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
>>>
>>> ___
>>> 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
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
tially taking
>> corrective and/or alternative action. Seems awfully limiting, as most of
>> the time the only option will be the vanilla "OMPI_ERROR".
>>
>> Thoughts?
> --
> Brian W. Barrett
> Dept. 1423: Scalable System Software
> Sandia National Laboratories
>
>
>
>
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
especially since the code turned out to be fairly subtle,
un-commented, and different than what has been done in the past.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
aram value, likely still resulting in a segv.
Does anyone have heartburn if I change the error behavior to
opal_finalize()/exit(1)?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
We talked about this on the call today.
A good suggestion was made: call show_help/opal_finalize/exit only when
OPAL_ENABLE_DEBUG is true. Otherwise, return an error code.
If no one objects to this, I'll commit this tomorrow.
On Oct 31, 2011, at 4:16 PM, Jeff Squyres wrote:
> WHAT:
, at 4:50 PM, George Bosilca wrote:
> This is a much saner solution. We [mostly] stayed away from calling exit deep
> into our libraries, there is no reason to add it now. I'll vote in favor of
> show_help + return code.
>
> george.
>
> On Nov 1, 2011, at 15:14 , Je
trong opinions here? I don't.
I offer the following two points:
- this is a coding error on the OMPI developer
- it's pretty rare
On Nov 1, 2011, at 7:30 PM, George Bosilca wrote:
> 1
>
> george.
>
> On Nov 1, 2011, at 17:23 , Jeff Squyres wrote:
>
>> Can you cl
ensure
> a quick complaint on one of our mailing lists and increase the probability of
> a [very] quick fix.
>
> george.
>
> On Nov 2, 2011, at 06:26 , TERRY DONTJE wrote:
>
>>
>>
>> On 11/1/2011 7:48 PM, Jeff Squyres wrote:
>>> So this was sli
btedly be a settling period for a change
of this magnitude while we shake out the inevitable bugs as we encounter new
environments and use-cases.
We appreciate your patience in advance.
Ralph, Jeff, Josh, and Terry
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http
> Or, is it possible that this support might not go into the first 1.6 release?
> I'm willing to make the changes, but just wanted some guidance on what to
> expect in 1.6.
1.6 will be a direct roll-over from the last 1.5.x (per
http://www.open-mpi.org/software/ompi/vers
>>> MPI_Allreduce, and the call to MPI_Waitall hangs.
>>>
>>> Is this a known issue? Is MPI_Allreduce not designed to work alongside
>>> the nonblocking routines? Is there a "safe" variant of MPI_Allreduce I
>>> should be using instead?
>>&
ts a lock. Each process has
> its own file and the test usually passes, so it's unclear to me what the
> problem is. Further, the error message discussing NFS and Lustre strikes me
> as rather speculative. We tend to run these tests repeatedly on the same
> file systems from t
l of the call stack). If you want to show_help
>>> and
>>> abort on debug, that makes sense. It doesn't make any sense on a
>>> production build. Return an error code and let the upper layer deal
>>> with
>>> it.
>>>
>>> Brian
; @@ -879,6 +880,7 @@
>> break;
>>
>> case MCA_BTL_IB_CONNECTING :
>> + assert(rem_info.rem_qps != NULL);
>> set_remote_info(ib_endpoint, &rem_info);
>> if (OMPI_SUCCESS != (rc = qp_connect_all(ib_endpoint))) {
>> BTL_ERROR(("endpoint connect error: %d", rc));
>> ___
>> svn-full mailing list
>> svn-f...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/svn-full
>>
>
>
>
> --
> Tim Mattox, Ph.D. - http://homepage.mac.com/tmattox/
> timat...@open-mpi.org || tmat...@gmail.com
> I'm a bright... http://www.the-brights.net/
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
t; -vader_memmove ((void *) dst->seg_key.ptr, rem_ptr, size);
> +vader_memmove ((void *) dst->seg_key.ptr[0], rem_ptr, size);
>
> vader_return_registration (reg, endpoint->peer_smp_rank);
>
>
> Modified: trunk/ompi/mca/btl/vader/btl_vader_put.c
> ==
> --- trunk/ompi/mca/btl/vader/btl_vader_put.c (original)
> +++ trunk/ompi/mca/btl/vader/btl_vader_put.c 2011-11-06 11:19:09 EST (Sun,
> 06 Nov 2011)
> @@ -34,15 +34,15 @@
> void *rem_ptr;
>
> reg = vader_get_registation (endpoint->peer_smp_rank,
> - (void *) dst->seg_key.ptr,
> + (void *) dst->seg_key.ptr[0],
> dst->seg_len, 0);
> if (OPAL_UNLIKELY(NULL == reg)) {
> return OMPI_ERROR;
> }
>
> -rem_ptr = vader_reg_to_ptr (reg, (void *) dst->seg_key.ptr);
> +rem_ptr = vader_reg_to_ptr (reg, (void *) dst->seg_key.ptr[0]);
>
> -vader_memmove (rem_ptr, (void *) src->seg_key.ptr, size);
> +vader_memmove (rem_ptr, (void *) src->seg_key.ptr[0], size);
>
> vader_return_registration (reg, endpoint->peer_smp_rank);
>
> ___
> svn-full mailing list
> svn-f...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/svn-full
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
gt;
>>>opal_convertor_get_current_pointer (convertor, (void **) &data_ptr);
>>>
>>> -frag->segment.seg_key.ptr = (uintptr_t) data_ptr;
>>> +frag->segment.seg_key.ptr[0] = (uintptr_t) data_ptr;
>>>frag->segment.seg_len =
han
>
> On Mon, 7 Nov 2011 09:14:21 -0500, Jeff Squyres wrote:
>> Just curious -- why was it necessary to increase the size of the 8, 32,
> and
>> 64 arrays?
>>
>>
>> On Nov 6, 2011, at 11:19 AM, hje...@osl.iu.edu wrote:
>>
>>> Author:
e.
Ah, I see.
I would put the other sizes back, at a minimum. There should be no need to
increase those.
George -- comments? Should this be a new key fields (128, with 2 uint64_t's)?
If this is only for large messages, is the extra 8 bytes a concern?
--
Jeff Squyres
jsquy...@cisco.c
dors. Of
course, appropriate testing with various debuggers and tools out there should
be a given -- current versions of DDT, Totalview, and padb are probably the 3
most obvious ones with which to test; others have mentioned some "stat," too.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
ative impact.
FWIW, I think I'd like to see a rollback of the increase of array sizes in the
seg_key union. They weren't necessary and might be slightly misleading.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
volatile int MPIR_i_am_starter = 0;
> +int MPIR_i_am_starter = 0;
> int MPIR_partial_attach_ok = 1;
> -volatile char MPIR_executable_path[MPIR_MAX_PATH_LENGTH];
> -volatile char MPIR_server_arguments[MPIR_MAX_ARG_LENGTH];
> +char MPIR_executable_path[MPIR_MAX_PATH_LENGTH];
> +char MPIR_s
mind that this is pretty much the same rationale as to why MPI still
supports functions like MPI_ATTR_SET: even though it's deprecated, there's apps
out there that still use it and will take a long time to adapt. Hence, the
tools will keep supporting the "old" / "not-quit
een ompi-trunk/ompi-1.5 in the
opal/mca/hwloc/hwloc122ompi/hwloc trees.
Terry: did you add some stuff to the trunk in topology-solaris-chiptype.c, for
example?
If so, the right solution might just be to copy from
trunk/opal/mca/hwloc/hwloc122ompi/hwloc/* to
ompi-1.5/opal/mca/hwloc/hwloc122ompi
s
perspective.
4. Cute names rarely seem so after 6 months.
I'll even volunteer to do the work to rename it (a bunch of file moves and
global search-and-replaces).
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
-rw-r--r-- 1 bef bef 1115 May 5 2010 atomic-asm.o
> lrwxrwxrwx 1 bef bef65 May 5 2010 atomic-asm.S ->
> ../../../../openmpi-1.4.2/opal/asm/generated/atomic-amd64-linux.s
> -rw-r--r-- 1 bef bef 873 May 5 2010 libasm.la
> -rw-r--r-- 1 bef bef 54526 Oct 14 16:19 Makefile
>
> Bruce
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
t;> ___
>> 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
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
hrock CTR SMDC SimCtr/GaN Corporation
> Cc: Open MPI Developers; Eugene Loh
> Subject: Re: [OMPI devel] PGI error invoked when svnversion is unavailable
>
> Tom,
>
> This is because the code in OpenMPI presumes macros will be expanded in
> pragmas, but that is not required by the C standard. (See my e-mails below
> from last year with PGI, TPR 17186.) I fixed OpenMPI 1.4.3 configure in the
> attached patch. My patch also disables inline assembly for PGI C++, the
> same as for PGI C. (Something similar may also have to be done to solve
> Eugene's asm statement warnings on Solaris 11.) It also fixes detection of
> support for marshaling Fortran REAL16 and COMPLEX32 data types.
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
discussed on the list. This will likely be in early/mid December.
On Nov 17, 2011, at 8:11 AM, Jeff Squyres wrote:
> After having to explain to someone at SC for the umpteenth time this week
> that the "vader" BTL uses the XPMEM transport under the covers, I'd like to
>
pens in the openib btl how does it identify itself? Does it use
> openib or ofrc? This seems like there could be some user confusion by
> adopting the aliasing scheme.
>
> --td
>
> On 11/22/2011 9:22 AM, Jeff Squyres wrote:
>> Here's what Nathan and I discussed
Can you explain that a little more? Are you -10'ing the whole concept? Or
just renaming xpmem? Or ...?
On Nov 22, 2011, at 11:37 AM, George Bosilca wrote:
> -10!
>
> george.
>
> On Nov 22, 2011, at 08:38 , Jeff Squyres wrote:
>
>> 1. Personally, I would lov
>
> What: fix for ticket 2157
>
> Question? Comments? Objections?
>
> -Nathan___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
--
>
> *Incorrect of definitions
> (MPI-2.1 standard defines these as not "const", but they are "const" in code)
> --
> MPI::Comm::Set_errhandler
> MPI::File::Set_errhandler
> MPI::Win::Set_errhandler
> ------
ikely have a 1.5.5rc1 shortly, too)
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
uot;, &st) ||
>>0 == stat("/dev/myri8", &st) ||
>>0 == stat("/dev/myri9", &st) ||
>> -0 == stat("/dev/ipath", &st)) {
>> +0 == stat("/dev/ipath", &st) ||
>> +0 == stat(&quo
quot;. Clearly it wasn't intended to be pushed yet.
>>
>> george.
>>
>> On Dec 12, 2011, at 18:58 , Jeff Squyres wrote:
>>
>>> Yes, it failed to compile for me, too.
>>>
>>> You could have just ompi-ignored it, Ge
t;>> ___
>>> 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
>>
>> ___
>> 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
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
llowed from creating temporary files by settings
> # the MCA parameter "orte_no_session_dir".
>
> I think you want s/settings/setting/ there.
Fixed! Thanks.
> Also I can not seem to make it accept the orte_no_session_dir settings,
> neither:
Did David's suggest
to call
free if we know the value will be NULL.
Did we talk about this before, and I was in the minority for thinking removing
it was a bad idea?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
e. Let me
file a ticket about it... Done:
https://svn.open-mpi.org/trac/ompi/ticket/2937
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Making the "your SM file is on an NFS!" warning disable-able
(this is the v1.4 ticket)
https://svn.open-mpi.org/trac/ompi/ticket/2937
They would both need to be fixed in the *immediate future* to be considered.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal informa
> +NULL,
>>>> +NULL
>>>> +);
>>>> +
>>>> +/*
>>>> //
>>>> */
>>>> +/**
>>>> + * this routine assumes that sorted_procs i
ific Linux SL release 5.5 (Boron)
>> $ uname -a
>> Linux [hostname] 2.6.18-238.1.1.el5 #1 SMP Tue Jan 18 18:49:37 EST 2011
>> x86_64 x86_64 x86_64 GNU/Linux
>> $ gcc --version | head -1
>> gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
>
> This is running (w/ actual h/w) gm
that line? Any other debuggers that
> might break?
>
> -Nathan
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal informat
ion that lives in debugger_base_fns.c. It's only purpose in life
would be to ensure that all the symbols -- including MPIR_Breakpoint -- are
pulled in at run time.
I'll go do that on the trunk right now...
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
htt
till) works for you with totalview and stat?
On Dec 15, 2011, at 1:35 PM, Jeff Squyres wrote:
> On Dec 15, 2011, at 10:28 AM, Ralph Castain wrote:
>
>>> I have had the chance now to test it with totalview and stat 1.1.0. Looks
>>> good. I pushed the fix to the trunk
ugged;
>> +OMPI_DECLSPEC extern volatile int MPIR_debug_state;
>> OMPI_DECLSPEC char *MPIR_debug_abort_string = "";
>>
>> /* Check for a file in few direct ways for portability */
>> ___
>> svn-full mailing list
>> svn-f...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/svn-full
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
t; 0060b9f8 B MPIR_proctable_size
> 0060b300 B MPIR_server_arguments
>
> -Nathan
>
> On Thu, 15 Dec 2011, Jeff Squyres wrote:
>
>> Ok, here's what I did:
>>
>> https://svn.open-mpi.org/trac/ompi/changeset/25660
>> --> pulls in symbo
gger_base_dump() before the return from
>>> orte_debugger_base_init_after_spawn(), it looks like this could also have
>>> been achieved via a debug setting but I couldn't see how.
>>
>>
>> _______
>> devel mailin
sts in
>> our message logging protocol. We hijack the send request list, and replace
>> them with our own, allowing us to chain all active requests. This make the
>> tracking of chive requests very simple, and minimize the impact on the
>> overall code.
>>
>> george.
>>
>
;>>>> Attached is a log showing the problem, the only change I made to the
>>>>>>>> source is to add a call to orte_debugger_base_dump() before the return
>>>>>>>> from orte_debugger_base_init_after_spawn(), it looks like this could
>>>>>>>> also have been achieved via a debug setting but I couldn't see how.
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> 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
>>>>>
>>>>>
>>>>> ___
>>>>> 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
>>>
>>>
>>> ___
>>> 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
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
If gdb and others can find them there, why can't launchmon? Does a
dlsym not find these symbols?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
$(PERL) '$(top_srcdir)/opal/asm/generate-asm.pl' '@OPAL_ASSEMBLY_ARCH@'
'@OPAL_ASSEMBLY_FORMAT@' '$(top_srcdir)/opal/asm/base'
'$(top_builddir)/opal/asm/generated/@OMPI_ASM_FILE@'
$1 should correspond to @OPAL_ASSEMBLY_ARCH@, and it should never be empty.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
011.
Happy holidays, everyone!
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
On Dec 20, 2011, at 6:20 PM, Jeff Squyres wrote:
> 2. Here are the issues that I am aware of:
>
> - VT build issues; they just filed a CMR today that may or may not be complete
> - shmem segv errors; Sam and Ralph are iterating on this and seem to be
> closing in on a fix
>
Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
; Joshua Hursey
> Postdoctoral Research Associate
> Oak Ridge National Laboratory
> http://users.nccs.gov/~jjhursey
> _______
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Please test:
http://www.open-mpi.org/software/ompi/v1.4/
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
interest -- no one asked for it, so we didn't allocate much/any time to it.
What's your interest level? Just curious? Gotta have it? Somewhere in
between?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
h I will report on later.
>>
>> -Paul
>>
>
> --
> Paul H. Hargrove phhargr...@lbl.gov
> Future Technologies Group
> HPC Research Department Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
ve this problem.
> So, we don't choose linear_sync in coll_tuned_decision_fixed.c.
>
> Best Regards,
>
> Yuki MATSUMOTO
> MPI development team,
> Fujitsu
>
> _______
> devel mailing list
> de...@open-mpi.org
> http://www.
e logic in there to
effectively handle ENOENT's, meaning that if we get a non-ESTALE error, we try
again with the directory name. This is repeated until we get to "/" -- so
there should definitely be at least one case where statfs() is *not* returning
ENOENT.
Is that not
E_DECLSPEC, for visibility),
and is properly instantiated in orte/mca/odls/base/odls_base_open.c.
Paul: can you run some nm's and see how the orte_odls symbol appears in
libopen-rte.a?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
t;>
>> - I'm far from sure that the way I have used CMA in OMPI is the best
>> way to do it, so any feedback is very welcome.
>>
>> Regards,
>>
>> Chris
>> --
>> cy...@au.ibm.com
>>
>>
>> __
2012-01-30 06:14:20 EST (Mon,
> 30 Jan 2012)
> @@ -27,6 +27,7 @@
> typedef struct mca_mtl_mxm_module_t {
> mca_mtl_base_module_t super; /**< base MTL interface */
> int verbose;
> +int enabled;
> mxm_h mxm_
-memory-manager was given, then we really don't want any
memory managers to be used.
NEWS and README updated
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
at if cm doesn't find any active
MTLs, it'll just disqualify itself, thereby falling back to ob1.
Right?
> Brian
>
> On 1/30/12 6:06 AM, "Jeff Squyres" wrote:
>
>> Mellanox --
>>
>> Isn't this redundant with the "pml" MCA param
>> 1.4.5rc2 as PASSing.
>> I will try to recheck all the FAILure cases I reported.
>>
>> If anybody wants me to retest any specific platforms, please let me know.
>>
>> I do see that Terry did NOT yet add "use CXX=CC but not CXX=sunCC" to the
>>
README updates noting systems that are no longer supported
Fix assembly generation code on BSD in v1.4
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
sts/devel/2012/01/10268.php , there are
> many instances of "defined(__linux__)" that seem to work fine. So, that
> alone should be fine.
Ok.
> -Paul
>
> On 1/31/2012 11:21 AM, Jeff Squyres wrote:
>> Hot on the heels of rc3, rc4 is out:
>>
>> http
hopefully fixes the problem!) is
around the corner.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
ied with the 1.4 work to pay
attention to the v1.5 stuff. Plus, I'm waiting for a new hwloc release before
making a new 1.5rc.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
On Jan 31, 2012, at 4:26 PM, Paul H. Hargrove wrote:
> I think the fix is just "$(RM)" -> "rm", since bare "rm" is used pretty
> widely in other Makefile.am's.
Done.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://
, but there were a few
additional bug fixes, so it seems like a good idea to do an actual final hwloc
1.3.x release and put that in OMPI 1.5.x/1.6.x so that it can have a long shelf
life.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doi
to be clear, you're *not*
saying this is the BSD/ROMIO problem with 1.4.5rc, right?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
ement with s/Apache/Open MPI/g). It's annoying, I know :-(, but we have to
keep the intellectual property of Open MPI "clean" so that it can guaranteed to
remain BSD:
http://www.open-mpi.org/community/contribute/
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
On Feb 1, 2012, at 5:36 PM, Dmitri Gribenko wrote:
>> Depending on the patch, however, we might need a signed Open MPI
>> contribution agreement from you/your employer
>
> That's fine for us.
Excellent. :-)
It all sounds good to me!
--
Jeff Squyres
jsquy...@
345, Unreleased developer copy
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
301 - 400 of 4318 matches
Mail list logo
