Also to clarify:
- did autogen set am-jobs to 2 in your case? (it should do that if lstopo is
not found - it also limits itself to 4 at max)
- in the same scenario, what happens if you manually set am-jobs to 1 and run
autogen? Ie do you get the same heat/sluggishness? I have experienced vms
Btw it strikes me that we could put the old libevent back as a separate
component for comparisons.
Sent from my PDA. No type good.
On Oct 26, 2010, at 6:20 AM, "Jeff Squyres" wrote:
> On Oct 25, 2010, at 9:29 PM, George Bosilca wrote:
>
>> 1. Not all processes deadlock in btl_sm_add_procs.
Yep - I get these mails, too.
My only comment is: %}%%€<>~|%>€€!!!
I swear I actually do test these things and they *do* work before I commit
them. There must be some difference between my env and the nightly creation
env. I'll investigate...
Sent from my PDA. No type good.
On Nov 3, 2010,
Sorry for the delay in replying - many of us were at SC last week.
Admittedly, I'm looking at your code on a PDA, so I might be missing some
things. But I have 2 q's:
1 your send routine doesn't seem to protect from sending to yourself. Correct?
2 you're not using nonblocking sends, which, if
Ya, it sounds like we should fix this eager limit help text so that others
aren't misled. We did say "attempt", but that's probably a bit too subtle.
Eugene - iirc: this is in the btl base (or some other central location) because
it's shared between all btls.
Sent from my PDA. No type good.
Beware that MPI-request-free on active buffers is valid but evil. You CANNOT be
sure when the buffer is available for reuse.
There was a sentence or paragraph added yo MPI 2.2 describing exactly this
case.
Sent from my PDA. No type good.
On Nov 23, 2010, at 5:36 PM, Sébastien Boisvert
wro
I'd guess thesame thing as George - a race condition in the shutdown of the
async thread...? I haven't looked at that code in a long log time to remember
how it tried to defend against the race condition.
Sent from my PDA. No type good.
On Jan 3, 2011, at 2:31 PM, "Eugene Loh" wrote:
> Geo
I'd rather not setup another SVN repo. Where should it go in the current OMPI
SVN?
Sent from my PDA. No type good.
On Jan 19, 2011, at 5:01 PM, "George Bosilca" wrote:
>
> On Jan 19, 2011, at 16:44 , Jeff Squyres wrote:
>
>> Where should it be on the main web site?
>
> The Documentation
Is there a version in a pthreads header file that can be checked?
You're right that I am currently checking Linux kernel version, not pthread
version. Note that this is *only* in cross-compiling environments; in non cross
compiling situations, we actually test the behavior to see if threads have
K. When Ralph and I removed that code, it was on he educated guess that no one
was using it (because it hasn't compiled right in a while). If we were wrong,
it can be put back, but someone will need to update it and Ralph and I don't
have access to machines to test that behavior.
Sent from my
Nick's right - changing your test program to use ierr instead of 0 makes it
compile on OMPI for me. Hence, the F90 module is actually doing exactly what
it is supposed to do: tell you when you have a compile time error in your code.
:)
I'm not sure why it compiles for you on MPICH - perhaps th
VT guys - please fix.
Sent from my phone. No type good.
Begin forwarded message:
> From: MPI Team
> Date: June 22, 2011 9:42:42 PM EDT
> To: test...@open-mpi.org
> Subject: === CREATE FAILURE (trunk) ===
> Reply-To: de...@open-mpi.org
>
>
> ERROR: Command returned a non-zero exist status (
Automake, I guess - that's what does the deps.
Sent from my phone. No type good.
On Jun 30, 2011, at 10:28 AM, "Ralph Castain" wrote:
> I'm surprised that autogen/configure wouldn't catch this, yet it clearly
> doesn't. I guess it's because the file moved?
>
> Seems like a bug in the autoto
Do u know which object it is that is being constructed? When you compile with
debugging enabled, theres strings in the object struct that identify te file
and line where the obj was created.
Sent from my phone. No type good.
On Jun 29, 2011, at 8:48 AM, "Xin He" wrote:
> Hi,
>
> As I adva
Does your llp sed path order MPI matching ordering? Eg if some prior isend is
already queued, could the llp send overtake it?
Sent from my phone. No type good.
On Jun 29, 2011, at 8:27 AM, "Kawashima" wrote:
> Hi Jeff,
>
>>> First, we created a new BTL component, 'tofu BTL'. It's not so spe
Were all the issueswith this code fixed? There were m4 issues and solaris
issues, IIRC.
Sent from my phone. No type good.
On Jun 28, 2011, at 9:28 AM, "klit...@osl.iu.edu" wrote:
> Author: kliteyn
> Date: 2011-06-28 10:28:29 EDT (Tue, 28 Jun 2011)
> New Revision: 24830
> URL: https://svn.op
Rolf -
Can you send a cumulative SVN diff against the SVN HEAD?
Sent from my phone. No type good.
On Jul 28, 2011, at 5:52 PM, "Rolf vandeVaart" wrote:
> WHAT: Add CUDA registration of host memory in sm and openib BTLs.
>
>
>
> TIMEOUT: 8/4/2011
>
>
>
> DETAILS: In order to improve pe
Te question that needs to be answered in the readme is: when should one se
openib/ob1 vs. Mxm? Users will need to know thus.
Also see the part in the readme about te different PMLs - u might want to write
more there.
Sent from my phone. No type good.
On Aug 2, 2011, at 10:30 AM, "mi...@osl
Terry -
Did #2887 fix this already?
Sent from my phone. No type good.
On Oct 18, 2011, at 6:19 AM, "Open MPI" wrote:
> #2888: base.h inclusion breaks Solaris build
> +
> Reporter: tdd | Owner: tdd
>Type: defect | Status:
Never mind; I just ready your text more carefully - 2887 caused the problem.
Sent from my phone. No type good.
On Oct 18, 2011, at 6:19 AM, "Open MPI" wrote:
> #2888: base.h inclusion breaks Solaris build
> +
> Reporter: tdd | Owner:
Paul -
Are you running autogen from the tarballs in your testing? You probably
shouldn't - we have users just run configure and make. We also bootstrap the
tarballs w the most recent config.sub and .guess (i.e., more recent than what
comes w the most recent Autotools).
Sent from my phone. No
es or the ones from your Autotools.
Sent from my phone. No type good.
On Dec 21, 2011, at 8:41 AM, "Paul H. Hargrove" wrote:
> I only ran autogen after I had edited a Makefile.am or a .m4 file.
>
> -Paul
>
> On 12/21/2011 4:58 AM, Jeff Squyres (jsquyres) wrote:
&g
Check out #220 now; I updated it.
Sent from my phone. No type good.
On Feb 10, 2012, at 4:46 PM, "Jeff Squyres" wrote:
> On Feb 10, 2012, at 3:32 PM, Paul H. Hargrove wrote:
>
>> The point of the question isn't related to WHY eth8 is useless - just assume
>> it is.
>> Assume it is UP, but u
That is truly bizarre "make" behavior.
Heads up that in the upcoming fortran revamp, we *only* use FC. I.E., there's
only mpifort wrapper compiler (mpif77 and mpif90 still exist, but only as sym
links to mpifort, signifying that mpifort is the way of the future).
This was done because there h
Terry -
Please add te fortran revamp to the agenda tomorrow. Thanks.
Sent from my phone. No type good.
George will have to answer that in detail, but note that if you modify the
tuned coll module source code, you can simply "make install" in
ompi/mca/coll/tuned. That will re-build the coll tuned module and install it
in the plugin directory. You don't even need to recompile your MPI app, since
I wrote a chapter about Open MPI in "The Architecture of Open Source
Applications, volume 2", which was just made available in dead tree form
today:
http://blogs.cisco.com/performance/the-architecture-of-open-source-applicat
ions-volume-ii/
All royalties from this book go to Amnesty Internationa
Can you send some output showing that those flags aren't passed through, like
some output from "make V=1" and or from config.log?
Offhand, I don't know if we ever formally supported setting env variables other
than enable and with flag variables in the platform files...?
Sent from my phone. No
FWIW: Ralph, I think Mike is proposing that we use the built in github SVN
functionality. I.E., you can use git or SVN - both can read or write to the
same backend repo. Pretty clever of github, actually. See the github blog entry
he referenced, if you care.
But I agree: although dvcs are very
Fwiw, we have put in many hours of engineering to "that obscene hack" *because*
compilers all have differing degrees of compatibility suck. It's going to be
years before compilers fully support f08, for example, so we have no choice but
to test for various compiler characteristics at configure t
Wait.
Why did we just add a version check for m4?
Sent from my phone. No type good.
On Nov 15, 2012, at 9:43 AM, "Hjelm, Nathan T" wrote:
> Committed as r27615. Let me know if there are any more issues.
>
> -Nathan
>
>
> From: devel-boun...@open-mpi
ly because we call out a minimum required version in our HACKING file, but
> we never check for it
>
> If we don't require a min version, then we shouldn't check - but if we do,
> then we should
>
> On Nov 15, 2012, at 9:00 AM, "Jeff Squyres (jsquyres)"
&g
t;
>
> On Nov 15, 2012, at 10:27 AM, "Jeff Squyres (jsquyres)"
> wrote:
>
>> We only call out te version of m4 because the Autotools we require need that
>> m4 version (which is not always already installed). We don't need that
>> version of m4 for OM
Per discussion and RFC, on the trunk (i.e., what will someday be OMPI v1.9),
the MPI C++ bindings are no longer built by default.
You can enable them via the configure switch --enable-mpi-cxx.
Those who are running MTT, you probably want to add --enable-mpi-cxx to your
OMPI configuration so t
Greetings Phil. Good analysis.
You can thank OFED for this horribleness, BTW. :-) Since OFED hardware
requires memory registration, and since that registration is expensive, MPI
implementations cache registered memory to alleviate the re-registration costs
for repeated memory usage. But MPI
On Jan 9, 2013, at 10:30 PM, Yoshiki SATO
wrote:
> The 1.7's Java implementation under ompi/mpi/java seem to be able to build up
> independently. Do you think we can build just them and run it (via
> prunjava?) with our custom OpenMPI build based on 1.6?
Yes -- IIRC, the Java interface isn'
s is still the state of affairs :)
>
> Thanks for addressing this so quickly. This will definitely make life easier
> for some Darshan and Open MPI users in the future.
>
> -Phil
>
> On 01/09/2013 04:24 PM, Jeff Squyres (jsquyres) wrote:
>> Greetings Phil. Good anal
Check the HACKING file in the top-level directory if you need some assistance
on how to upgrade your Autoconf/Automake/Libtool.
On Jan 9, 2013, at 9:27 PM, Ralph Castain
wrote:
> I'm pretty sure we are at autoconf 2.69 now. You might want to upgrade it,
> and ensure your m4 is correspondingl
It looks like a recent change to btl_openib_endpoint.h is resulting in warnings
-- the code is a bit ambiguous:
-
if (ep->qps[qp].qp->sd_wqe <= 0 ||
size + sizeof(mca_btl_openib_header_t) + (rdma ?
sizeof(mca_btl_openib_footer_t) : 0) > ep->qps[qp].ib_inline_max ||
On Jan 10, 2013, at 10:33 AM, Yoshiki SATO wrote:
>> Yes -- IIRC, the Java interface isn't really dependent upon anything
>> specific in the back-end C implementation of Open MPI. So I'm
>> guessing/assuming that if you can build it, it should work against the 1.6
>> OMPI C engine just fine.
In the usual location:
http://www.open-mpi.org/software/ompi/v1.7/
I don't have an easy list of things that have changed since rc6; *many* things
have changed / been fixed. Please test.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/abo
Not that I'm aware of; that would be great.
Unlike George, however, I'm not concerned about converting to linear operations
for attributes.
Attributes are not used often, but when they are:
a) there aren't many of them (so a linear penalty is trivial)
b) they're expected to be low performance
Given that we've screwed this up before, could someone please sanity check the
.so versions I'm planning on using for the 1.6.4 release. Only 2 libraries
changed: libmpi and libopen-pal (most other changes were in VT and various
components). No interfaces changed.
Is this right?
## libmp
In the usual location:
http://www.open-mpi.org/software/ompi/v1.6/
Here's a list of changes since 1.6.3:
- Added performance improvements to the OpenIB (OpenFabrics) BTL.
- Improved error message when process affinity fails.
- Fixed MPI_MINLOC on man pages for MPI_REDUCE(_LOCAL). Thanks to
Sweet. :)
Sent from my phone. No type good.
On Jan 17, 2013, at 6:59 PM, "Paul Hargrove"
mailto:phhargr...@lbl.gov>> wrote:
On Thu, Jan 17, 2013 at 2:26 PM, Paul Hargrove
mailto:phhargr...@lbl.gov>> wrote:
[snip]
The BAD news is a new failure (SEGV in orted at exit) on OpenBSD-5.2/amd64,
whic
On Jan 17, 2013, at 8:43 PM, "Kawashima, Takahiro"
wrote:
> Fujitsu is interested in completing MPI-2.2 on Open MPI and Open MPI
> -based Fujitsu MPI.
>
> We've read wiki and tickets. These two tickets seem to be almost done
> but need testing and bug fixing.
>
> https://svn.open-mpi.org/trac
George --
Should I pull from your repo into
https://bitbucket.org/jsquyres/ompi-topo-fixes-fixed? Or did you effectively
fork, and you guys will put back to SVN when you're done?
On Jan 18, 2013, at 5:47 AM, George Bosilca
wrote:
> Takahiro,
>
> The MPI_Dist_graph effort is happening in
eorge.
>
> On Jan 18, 2013, at 15:42 , "Jeff Squyres (jsquyres)"
> wrote:
>
>> George --
>>
>> Should I pull from your repo into
>> https://bitbucket.org/jsquyres/ompi-topo-fixes-fixed? Or did you
>> effectively fork, and you guys will p
Done -- thank you!
On Jan 11, 2013, at 3:52 AM, "Kawashima, Takahiro"
wrote:
> Hi Open MPI core members and Rayson,
>
> I've confirmed to the authors and created the bibtex reference.
> Could you make a page in the "Open MPI Publications" page that
> links to Fujitsu's PDF file? The attached f
Leif --
We talked about this a bit on our weekly call today.
Just to be sure: are you saying that George's patches are *functionally
correct* for ARM5/6/7 (and broken for ARM 4), but it would be better to
organize the code a bit better?
If that is correct, was ARM4 working before?
If ARM4 wa
George --
Is there any reason not to CMR this to v1.6 and v1.7?
On Jan 21, 2013, at 6:35 AM, svn-commit-mai...@open-mpi.org wrote:
> Author: bosilca (George Bosilca)
> Date: 2013-01-21 06:35:42 EST (Mon, 21 Jan 2013)
> New Revision: 27880
> URL: https://svn.open-mpi.org/trac/ompi/changeset/2788
George --
Similar question on this one: should it be CMR'ed to v1.7? (I kinda doubt it's
appropriate for v1.6)
On Jan 21, 2013, at 6:41 AM, svn-commit-mai...@open-mpi.org wrote:
> Author: bosilca (George Bosilca)
> Date: 2013-01-21 06:41:08 EST (Mon, 21 Jan 2013)
> New Revision: 27881
> URL:
y cared about error cases so far, I don't personally see any incentive
> to push this patch in the 1.7 right now. But I won't be against as it is not
> hurting either.
>
> George.
>
>
> On Jan 22, 2013, at 16:28 , "Jeff Squyres (jsquyres)"
> wrote:
&g
On Jan 23, 2013, at 10:27 AM, George Bosilca wrote:
> While we always strive to improve this functionality, it was available as a
> separate software packages for quite some time.
What separate software package are you referring to?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal infor
On Jan 23, 2013, at 9:55 AM, Leif Lindholm wrote:
> To summarize the out-of-line assembler changes of this patch:
> - The patch is functionally correct for ARMv7 (which we know, because the code
> - It also appears to be functionally correct for ARMv6, given reports of
> - It *might* be functiona
onest it was hanging in one of my repos for some time. If I'm not
>> mistaken it is somehow related to one active ticket (but I couldn't find the
>> info). It might be good to push it upstream.
>>
>> George.
>>
>> On Jan 22, 2013, at
On Jan 24, 2013, at 8:18 AM, Leif Lindholm wrote:
> OK. In which case I probably _should_ be on that list.
> *cough* might I however suggest that a statement to that effect is added
> to http://www.open-mpi.org/community/lists/ompi.php ?
Fair point. Done.
>> I tested this patch in v1.6 and v1.
On Jan 25, 2013, at 7:28 AM, Leif Lindholm wrote:
>> Mmm. Ok. So is this a correct list of what is supported right now (i.e.,
>> in v1.6 with your patch)
>> ARM4: no
>> ARM5: no
>> ARM6: sorta (not multi-core, or anywhere we would need barriers)
>> ARM7: yes
>
> Correct, that is what is suppo
In the usual location:
http://www.open-mpi.org/software/ompi/v1.6/
Changes since rc1:
- Automatically provide compiler flags that compile properly on some
types of ARM systems.
- Fix slot_list behavior when multiple sockets are specified. Thanks
to Siegmar Gross for reporting the proble
First off, 1.4.4 is fairly ancient. You might want to try upgrading to 1.6.3.
Second, you might want to use non-blocking receives for B such that you can
MPI_WAITALL, or perhaps MPI_WAITSOME or MPI_WAITANY to wait for some/all of the
values to arrive in B. This keeps any looping down in MPI (i
I'll +1 what Brian said: we *really* don't want to have to link Open MPI with a
C++ compiler.
Can't you rpath in whatever support libraries you need (e.g., the g++ libraries
with the cxx_personality symbol), such that when we -ltorque, it just pulls in
whatever other dependencies it needs?
(I'
You're basically telling your build system to use a C++ compiler as the linker
when creating libtorque. This probably does more-or-less what I suggested:
rpath'ing in whatever dependencies you need such that when we link against
libtorque, all of the (C++) dependencies that you need are automat
y issue.
>
> On Sat, Jan 26, 2013 at 7:32 AM, Jeff Squyres (jsquyres)
> wrote:
> First off, 1.4.4 is fairly ancient. You might want to try upgrading to 1.6.3.
>
> Second, you might want to use non-blocking receives for B such that you can
> MPI_WAITALL, or perhaps MPI
Thanks Josh.
Steve -- if you can confirm that this fixes your problem in the v1.6 series,
we'll go ahead and commit the patch.
FWIW: the OpenFabrics startup code got a little cleanup/revamp on the
trunk/v1.7 -- I suspect that's why you're not seeing the problem on trunk/v1.7
(e.g., look at the
WHAT: Remove the configure command line option to enable heterogeneous support
WHY: The heterogeneous conversion code isn't working, very few people use this
feature
WHERE: README and config/opal_configure_options.m4. See attached patch.
TIMEOUT: Next Tuesday teleconf, 5 Feb, 2013
MORE DETAIL
On Jan 28, 2013, at 8:46 AM, Leif Lindholm wrote:
> But giving some flexibility for roadblocks, can we say "this quarter"?
Cool.
> Apart from our *cough* convoluted architecture vs. processor naming scheme...
> It should be ARMv4, ARMv5, ARMv6 and ARMv7.
Fixed in the README; thanks.
>> --> D
It's on the ticket that I just assigned to you. :-)
On Jan 29, 2013, at 10:03 AM, Steve Wise wrote:
> Will do...once I get a patch.
>
> STeve
> On 1/29/2013 7:40 AM, Jeff Squyres (jsquyres) wrote:
>> Thanks Josh.
>>
>> Steve -- if you can confirm that
Agreed. I like the idea, and recognize that it is inspired by Linux kernel
macros. But I would prefer them to be upper case to match our conventions.
Also, please be sure to put in good comments explaining their use in the .h
file.
Thanks!
On Jan 29, 2013, at 12:18 PM, Ralph Castain wrote:
On Jan 30, 2013, at 7:36 AM, Siegmar Gross
wrote:
> HiI have no problem with the option --enable-heterogeneous, when I build
> Open MPI, but Open MPI will not work in a heterogeneous environment
> with little and big endian machines,
Right -- that's the issue: --enable-heterogeneous is broken (
On Jan 30, 2013, at 9:40 AM, Andreas Schäfer wrote:
> But isn't heterogeneity the main reason for having MPI datatypes in
> the first place? Otherwise I could always use MPI_CHAR and sizeof(Foo).
Heterogeneity was a much bigger issue back in the 90s. Nowadays, most people
have pretty homogeneo
In the usual place:
http://www.open-mpi.org/software/ompi/v1.6/
Changes since rc2:
- Fix a seg fault in the openib BTL when no connection method can be found.
This is looking pretty stable; it could well be the last rc.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go
I'm seeing a LOT of these on errors on the trunk:
pml_ob1_sendreq.c:188 FATAL
The job then hangs. I see this starting at np=6 across 2 nodes, using only the
TCP and SM BTLs. This is not happening on v1.6 or v1.7. Line 188 in
pml_ob1_sendreq.c is when someone calls mca_pml_ob1_match_compl
The show help bit doesn't look right -- opal_output on stream 0 will put the
hostname and PID as the prefix.
On Jan 31, 2013, at 6:13 PM, Ralph Castain
wrote:
> I fixed it so that "abort" really aborts the job - see r28004
>
> On Jan 31, 2013, at 2:02 PM, Jeff Squy
+1.
Nathan and I have been talking about this for quite a while. Note that this is
the first of several updates that we will have for the MCA param system -- we
have a roadmap that can be easily described as two groups of things:
1. Changes that are intended for v1.7.x: everything to support M
On Feb 1, 2013, at 6:28 PM, George Bosilca wrote:
> So far, all interfaces specified via MCA parameters for the BTL TCP
> are required to exist. Otherwise an error message is printed and an
> error returned to the upper level, with the intent that no BTLs of
> this type will be enabled (as an exa
On Feb 1, 2013, at 7:09 PM, George Bosilca wrote:
> I did not say we abort, I say we prevent BTL TCP from being used.
Ah.
> In your example, I guess the TCP is disabled but the PML finds another
> available interface and keeps going. If I try the same thing with
> "--mca btl tcp,self" it does a
On Feb 1, 2013, at 9:59 PM, "Barrett, Brian W" wrote:
> I don't think this is right either. Excluding a device that doesn't exist has
> many use cases. Such as disabling a network that only exists on part of the
> cluster. I'm not sure about what to do with seq; it's more like include than
>
On Feb 4, 2013, at 2:03 PM, George Bosilca wrote:
> The two behaviors you describe for include and exclude do not look
> conflicting to me. Inclusion is a strong request, the user enforce the usage
> of a specific interface. If the interface is not available, then we have a
> problem. Exclude
I think the point is that there are many cases throughout the OMPI code base
where we do exactly the things listed in these macros.
You certainly don't have to use them, but they can save a little effort when
you them.
On Feb 4, 2013, at 2:13 PM, George Bosilca wrote:
> Ralph,
>
> There are
? I can see it being a problem if we don't exclude something in
> the list, but the other way is (in my opinion) harmless but with a useful use
> case...
>
> Brian
>
>
>
> Sent with Good (www.good.com)
>
>
> -Original Message-
> From:
but I have the opposite use case; I have a device
> on some nodes and not others that I want to ignore, so I set
> btl_tcp_if_exclude to include that device. It would be totally
> counter-intuitive to have a giant warning because of that.
>
> Brian
>
> On 2/5/13 6:46 AM, &quo
BEFORE YOU PANIC: this only affects Open MPI v1.7 (which is not yet released)
and the OMPI SVN trunk (which is also, obviously, not released). ***OMPI
v1.6.x is unaffected/not GPL tainted***
Here's the full details:
It was just discovered yesterday that libpci, which hwloc links against for PC
On Feb 6, 2013, at 6:44 AM, Brice Goglin wrote:
> Do you already use hwloc's PCI objects in OMPI v1.7 ?
We enable the functionality; I'm not sure if anyone is actually looking at
specific PCI devices in the resulting hwloc tree.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal informati
Mellanox --
Was this commit a mistake?
Author: miked (Mike Dubman)
List-Post: devel@lists.open-mpi.org
Date: 2013-02-12 10:33:21 EST (Tue, 12 Feb 2013)
New Revision: 28048
URL: https://svn.open-mpi.org/trac/ompi/changeset/28048
Log:
Added new project: oshmem.
A
+1
On Feb 14, 2013, at 12:38 PM, "Barrett, Brian W" wrote:
> Hi all -
>
> I'd like to propose that we remove the support for Solaris threads in the
> trunk. Solaris provides a pthread implementation which is of equivalent
> performance and supporting two thread libraries is kind of a pain.
> P
http://www.open-mpi.org/software/ompi/v1.6/
Changes since rc3:
- Fix Cygwin shared memory and debugger plugin support. Thanks to
Marco Atzeri for reporting the issue and providing initial patches.
- Fix to obtaining the correct available nodes when a rankfile is
providing the allocation. Th
WHAT: Remove all Windows code from the trunk.
WHY: This issue keeps coming up over and over and over...
WHERE: Throughout the tree.
WHEN: Timeout: next Tuesday teleconf: 26 Feb, 2013
More detail:
It seems like every week, a new issue related to "what do we do about the
Windows code?" comes up
I guess the question is whether a java "long" is equivalent to a C "long",
"long long", or "long int"...
Do you know? (I'm not much of a Java guy)
On Feb 19, 2013, at 7:22 PM, Steve Angelovich wrote:
> All,
>
> We ran into a problem using openmpi from java with a Java data type of long
>
All MTT testing looks good for 1.6.4. There seems to be an MPI dynamics
problem when --enable-spare-groups is used, but this does not look like a
regression to me.
I put out a final rc, because there was one more minor change to accommodate an
MXM API change; it's in the usual place:
http
On Feb 20, 2013, at 12:37 PM, Ralph Castain wrote:
>> In Java, a long is always 64 bits. In C and Objective-C, a long might be 64
>> bits, or it might be 32 bits, or (in less common cases) it might be
>> something else entirely; the C standard doesn't specify an exact bit width.
>
> So we may
Wed, Feb 20, 2013 at 10:05 PM, Ralph Castain wrote:
>>>>>
>>>>> On Feb 20, 2013, at 11:39 AM, Dmitri Gribenko wrote:
>>>>>
>>>>>> On Wed, Feb 20, 2013 at 9:34 PM, Jeff Squyres (jsquyres)
>>>>>> wrote:
>>>>&
at 4:09 PM, Nathan Hjelm wrote:
> On Wed, Feb 20, 2013 at 10:28:56AM -0800, Eugene Loh wrote:
>> On 02/20/13 07:54, Jeff Squyres (jsquyres) wrote:
>>> All MTT testing looks good for 1.6.4. There seems to be an MPI dynamics
>>> problem when --enable-spare-groups i
Arrgh. I think you're going to make me eat my words
(http://www.open-mpi.org/community/lists/devel/2013/02/12143.php).
I just recently lost my access to InfiniBand test gear, so I can't test this
myself. Hypothetically, it should be fine. But throwing in an untested change
literally right
y the 2-byte alignment, although I would suspect it's for
>> performance reasons.
>>
>>
>> Josh
>>
>>
>> -----Original Message-
>> From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On
>> Behalf Of Jeff Squ
is fixed or will be fixed?
>
> Thanks,
> Steve
>
> On 02/20/2013 02:15 PM, Jeff Squyres (jsquyres) wrote:
>> I didn't misspeak in my email. :-)
>>
>> That being said:
>>
>> 1. If the Java sizes are fixed, great. It should make writing configury
Marco --
Is it just these 2 patches:
r28059 [[BR]]
Patch for Cygwin support: use correct DSO/shared library prefix and
suffix. Thanks to Marco Atzeri for reporting the issue and providing
an initial patch.
r28060 [[BR]]
Patch for Cygwin support: Use S_IRWXU for shmget() and include
. Thanks t
On Feb 25, 2013, at 6:30 PM, Pavel Mezentsev wrote:
> I've tried to build it but got different errors with different compilers.
>
> With Intel (2011.5.220) and pgi (13.2) I get the following error:
> CC bcol_iboffload_module.lo
> bcol_iboffload_module.c(37): catastrophic error: cannot open
stain wrote:
> Thanks Marco - I was hoping that would be the case!
>
>
> On Feb 18, 2013, at 8:42 AM, marco atzeri wrote:
>
>> On 2/18/2013 5:10 PM, Jeff Squyres (jsquyres) wrote:
>>> WHAT: Remove all Windows code from the trunk.
>>>
>>> W
On Feb 25, 2013, at 10:27 PM, marco atzeri wrote:
> plus the additional ones
>
> ERROR.patch : ERROR is already defined, so another label
> is needed for "goto ERROR"
Snipped.
I finally filed a ticket about this:
https://svn.open-mpi.org/trac/ompi/ticket/3527
We tal
The goal is to release 1.7 (final) by the end of this week. New rc posted with
fairly small changes:
http://www.open-mpi.org/software/ompi/v1.7/
- Fix wrong header file / compilation error in bcol
- Support MXM STREAM for isend and irecv
- Make sure "mpirun " fails with $status!=0
- Bunches
1 - 100 of 1833 matches
Mail list logo
