Re: [OMPI devel] v1.8 - compile/dist problem

the problem occurs when build is started from src.rpm (and probably from tarball as well): try make distcheck and use src tree from tarball. On Thu, Jul 24, 2014 at 10:57 AM, Bert Wesarg <bert.wes...@tu-dresden.de> wrote: > On 07/24/2014 09:32 AM, Mike Dubman wrote: > >> ye

Re: [OMPI devel] v1.8 - compile/dist problem

On Thu, Jul 24, 2014 at 11:58 AM, Bert Wesarg <bert.wes...@tu-dresden.de> wrote: > On 07/24/2014 10:15 AM, Mike Dubman wrote: > >> the problem occurs when build is started from src.rpm (and probably from >> tarball as well): >> >> try make distcheck and use

Re: [OMPI devel] v1.8 - compile/dist problem

have > clean/fresh checkouts of the OMPI tree. > > > > It does not seem to happen on RHEL 6.5, but does happen on RHEL 7 and > SLES 12 (beta). > > > > What's the difference? > > > > > > On Jul 24, 2014, at 6:12 AM, Mike Dubman <mi...@dev.mellanox.co

Re: [OMPI devel] oshmem only supports Linux ?

OSHMEM memheap implementation relies on the "_end" symbol provided by linux linker. The _end symbol indicates the beginning of the program dynamic allocation area. This is needed to allow programmatic access to the process global/static variables. On Thu, Jul 24, 2014 at 9:22 PM, Marco Atzeri

[OMPI devel] trunk compilation errors in jenkins

Making all in mca/common/ofacm make[2]: Entering directory `/hpc/local/benchmarks/hpc-stack-gcc/src/install/ompi-master/opal/mca/common/ofacm' CC libmca_common_ofacm_la-common_ofacm_base.lo CC libmca_common_ofacm_la-common_ofacm_oob.lo CC

Re: [OMPI devel] 1.8.2rc3 now out

Also, latest commit into openib (origin/v1.8 https://svn.open-mpi.org/trac/ompi/changeset/32391) broke something: *11:45:01* + timeout -s SIGSEGV 3m /scrap/jenkins/workspace/OMPI-vendor/label/hpctest/ompi_install1/bin/mpirun -np 8 -mca pml ob1 -mca btl self,openib

[OMPI devel] jenkins error in trunk

*Josh,Devendar - could you please take a look?* *Thanks* *15:45:00* Making install in mca/coll/fca*15:45:00* make[2]: Entering directory `/scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/ompi/mca/coll/fca'*15:45:00* CC coll_fca_module.lo*15:45:00* coll_fca_module.c: In

Re: [OMPI devel] jenkins error in trunk

org> wrote: > Fixed in r32462 > > On Aug 8, 2014, at 8:13 AM, Mike Dubman <mi...@dev.mellanox.co.il> wrote: > > > *Josh,Devendar - could you please take a look?* > > *Thanks* > > > *15:45:00* Making install in mca/coll/fca*15:45:00* make[2]: Entering >

Re: [OMPI devel] jenkins errors in origin/v1.8

yep, missed "green" report. Thanks On Sat, Aug 9, 2014 at 1:24 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> wrote: > Fixed with Ralph's commit last night (r32480). > > > On Aug 9, 2014, at 1:33 AM, Mike Dubman <mi...@dev.mellanox.co.il> wrote:

Re: [OMPI devel] jenkins error in trunk

r32484 On Sat, Aug 9, 2014 at 5:09 PM, Ralph Castain <r...@open-mpi.org> wrote: > Hmmmwell, I showed you how to fix them, so please feel free to do so > :-) > > I have no way to build that component. > > > On Aug 8, 2014, at 10:32 PM, Mike Dubman <mi...@dev.me

Re: [OMPI devel] RFC: Multiple duplicate MCA param generates error

maybe we should have another MCA parameter to specify desired policy? LAST,CONCAT,FIRST and let user select it? basically, it is to mimic "setenv(var,val,overwrite)" behavior which is easy to explain and good to have. On Tue, Sep 9, 2014 at 7:31 PM, Ralph Castain wrote: >

Re: [OMPI devel] [OMPI commits] Git: open-mpi/ompi branch master updated. dev-49-g86f1d5a

4f34092ad3f7a645d9a5ccbcb6c (commit) >> > from cd48fbeec67f1a511a9cf5ce890fef6cc535ef60 (commit) >> > >> > Those revisions listed above that are new to this repository have >> > not appeared on any other notification email; so we list those >> > revisions in full, below. >> > >> > - Log

Re: [OMPI devel] [OMPI commits] Git: open-mpi/ompi branch master updated. dev-78-g6372ac9

15a4831dfae9dd0a3fee7b31ee784d4e5394a4 (commit) > >> > >> Those revisions listed above that are new to this repository have > >> not appeared on any other notification email; so we list those > >> revisions in full, below. > >> > >> - Log

[OMPI devel] origin/v1.8 - compilation failed

*05:12:10* more information, such as the ld(1) and ld.so(8) manual pages. *05:12:10* -- *05:12:10* make[3]: Leaving directory `/scrap/jenkins/workspace/hpc-ompi-shmem/label/r-vmb-centos5-u7-x86-64/ompi/mca/btl/vader' *05:12:10*

Re: [OMPI devel] origin/v1.8 - compilation failed

https://github.com/open-mpi/ompi-release/pull/49 > > please note a similar warning is fixed in > https://github.com/open-mpi/ompi-release/pull/48 > > Cheers, > > Gilles > > On 2014/10/23 17:14, Mike Dub

Re: [OMPI devel] origin/v1.8 - compilation failed

macros were not backported to OMPI_*) > > i fixed it in https://github.com/open-mpi/ompi-release/pull/49 > > please note a similar warning is fixed in > https://github.com/open-mpi/ompi-release/pull/48 > > Cheers, > > Gilles > > On

Re: [OMPI devel] thread-tests hang

will fix it to keep old behave by enabling both flags if one of them is ON? Thanks On Wed, Nov 5, 2014 at 5:41 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> wrote: > On Nov 5, 2014, at 9:42 AM, Mike Dubman <mi...@dev.mellanox.co.il> wrote: > > > Hey Jeff, > > > >

Re: [OMPI devel] thread-tests hang

d passing only --enable-mpi-thread-multiple made it > work...? > > On Nov 5, 2014, at 11:37 AM, Mike Dubman <mi...@dev.mellanox.co.il> wrote: > > > the problem is that now the behavior is changed. > > Before: user provided single flag and could use MT support. >

Re: [OMPI devel] RFC: revamp btl rdma interface

btw, do you plan to add atomics API to MTL layer as well? On Thu, Nov 6, 2014 at 5:23 PM, Nathan Hjelm wrote: > At the moment I select the lowest latency BTL that can reach all of the > ranks in the communicator used to create the window. I can add code to > round-robin

Re: [OMPI devel] Jenkins vs master (and v1.8)

how about if I will disable the failing test(s) and make jenkins to pass? It will help us to make sure we don`t break something that did work before? On Tue, Nov 11, 2014 at 7:02 AM, Gilles Gouaillardet < gilles.gouaillar...@iferc.org> wrote: > Mike, > > Jenkins runs automated tests on each pull

Re: [OMPI devel] Jenkins vs master (and v1.8)

positive, but also remove an important piece of > information : > there is something wrong with the master. > > would you mind discussion this on the weekly call ? > > Cheers, > > Gilles > > > On 2014/11/11 17:38, Mike Dubman wrote: > > how about if I will disable the fai

Re: [OMPI devel] OMPI devel] Jenkins vs master (and v1.8)

rhel6.4 we can provide ssh access to interested parties. On Tue, Nov 11, 2014 at 2:01 PM, Gilles Gouaillardet < gilles.gouaillar...@gmail.com> wrote: > Thanks Mike, > > BTW what is the distro running on your test cluster ? > > Mike Dubman <mi...@dev.mellanox.co.il> wr

Re: [OMPI devel] omni-release Github comment bot

sounds cool and useful. Also, does it make sense to have "rebase" knob to cause "try rebase if no conflicts" with upstream? On Thu, Feb 5, 2015 at 2:04 PM, Jeff Squyres (jsquyres) wrote: > Gilles came up with a cool idea for the OMPIBot (see below). We can do > this idea,

Re: [OMPI devel] omni-release Github comment bot

yep, exactly. On Thu, Feb 5, 2015 at 2:35 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> wrote: > On Feb 5, 2015, at 7:20 AM, Mike Dubman <mi...@dev.mellanox.co.il> wrote: > > > > sounds cool and useful. > > K, thanks. > > > Also, does it make sense

Re: [OMPI devel] omni-release Github comment bot

gt; > > I'm thinking that the functionality you describe may become a different > bot...? I'm not sure. > > > > > >> On Feb 5, 2015, at 9:56 AM, Mike Dubman <mi...@dev.mellanox.co.il> > wrote: > >> > >> yep, exactly. > >> > &g

Re: [OMPI devel] Unwanted ibv_fork_init() mess(ages) and complaint for non-IB login node

Paul, judging by: libibverbs: Warning: couldn't open config directory '/etc/libibverbs.d'. libibverbs: Warning: no userspace device-specific driver found for /sys/class/infiniband_verbs/uverbs0 it seems that ofed userspace libraries version does not match loaded ofer kernel driver version. On

[OMPI devel] jenkins and openmpi

Hello, Please check updated OMPI wiki page for detailed information for Jenkins testing of OMPI repositories. https://github.com/open-mpi/ompi/wiki/PRJenkins Comments and suggestions are welcome. -- Kind Regards, M.

Re: [OMPI devel] Jenkins and coverity logs

Hi Gillies, Thanks for info, will take a look. We upgraded recently the jenkins server and it seems that default behave was changed and ws/cov_build/ folder now contains info for latest in-flight PR only :( Will check your advice as well. Thanks On Mon, May 25, 2015 at 9:02 AM, Gilles

Re: [MTT devel] mtt patch: summary digest

t; > Done! >> >> On Oct 28, 2008, at 2:06 AM, Mike Dubman wrote: >> >> > >> > Hey Jeff, >> > >> > I have no svn permissions to commit. Can you please provide me with >> > one? (login: miked) >> > Thanks >> > >

[MTT devel] mpi_details section with different scenarios for command line params

Hello Guys, Please suggest the proper way to handle the following: Is there any way to run "test run" section with a list of "mpi_details" sections? Or how to execute specific "Test run" section against specific "mpi_details" section, where "mpi_details" can have many different scenarios of

Re: [MTT devel] mpi_details section with different scenarios for command line params

Ethan, Thanks for the tip, nice way to achieve multi-scenarios for single mpi_details section. Mike. On Mon, Nov 3, 2008 at 5:45 PM, Ethan Mallove <ethan.mall...@sun.com> wrote: > On Mon, Nov/03/2008 09:34:07AM, Mike Dubman wrote: > >Hello Guys, > > > >Pl

Re: [MTT devel] mpi_details section with different scenarios for command line params

Ethan Mallove wrote: > > On Mon, Nov/03/2008 09:34:07AM, Mike Dubman wrote: >> >>> Hello Guys, >>> >>> Please suggest the proper way to handle the following: >>> >>> Is there any way to run "test run" section with a list >&g

Re: [MTT devel] mpi_details section with different scenarios for command line params

yep. it works. I thought that "exec" for mpirun will be executed once with all @mca@ params passed to it. Thanks again. Mike On Tue, Nov 4, 2008 at 2:08 PM, Jeff Squyres <jsquy...@cisco.com> wrote: > On Nov 4, 2008, at 1:18 AM, Mike Dubman wrote: > > Do you mean that y

Re: [MTT devel] GSOC apps now open

I`ll help, lead us master. On Tue, Mar 10, 2009 at 6:01 PM, Josh Hursey wrote: > Yeah I have some time to dedicate do this. We should talk about a couple of > specific topics to propose from this list we posted on the wiki. > > I can start digging in later this

Re: [MTT devel] mtt text report oddity

because the results are rendered in chunks during reporting phase. (100 pieces every flush) This caused same benchmark line to appear more then once in the final report. You can configure the reporter to issue results not by number, but for same benchmark at once: put this in the ini file:

Re: [MTT devel] [MTT svn] svn:mtt-svn r1273 (Analyze/Performance plug-ins)

Hello Eithan, Thanks for info, will refactor it. from http://www.netlib.org/benchmark/hpl/ ... *HPL* is a software package that solves a (random) dense linear system in double precision (64 bits) arithmetic on distributed-memory computers. It can thus be regarded as a portable as well as freely

Re: [MTT devel] GSOC application

Hello guys, I`m not sure if we should preserve current DB schema, from one simple reason - datastore is an object oriented storage and have different rules and techniques then rdbms. The basic storage unit in the datastore is an object which can be saved, loaded and queried. (hadoop is based on

Re: [MTT devel] GSOC application

week and likely won't be able to look > into this stuff -- can you guys post a proposal and we can dive into it from > that angle? > > > On Mar 22, 2009, at 6:48 AM, Mike Dubman wrote: > > Hello guys, >> >> I`m not sure if we should preserve current DB schema, from

Re: [MTT devel] GSOC application

Hello Guys, I have played a bit with google datastore and here is a proposal for mtt DB infra and some accompanying tools for submission and querying: 1. Scope and requirements a. provide storage services for storing test results generated by mtt. Storage services will be

Re: [MTT devel] GSOC application

Hello Guys, Please comment on the proposed object model and flows. We will have 1-2 ppl working on this in a 2-3w. Till that moment I would like to finalize the scope and flows. Thanks Mike. On Mon, Apr 6, 2009 at 4:54 PM, Mike Dubman <mike.o...@gmail.com> wrote: > Hello Guys, &

[MTT devel] Fwd: GSOC application

resending original post with attachment (mtt_datastore.tbz). it is sample google appengine API application. It contains models.py with object model proposal and script with some examples of object model use-cases and flows. -- Forwarded message -- From: Mike Dubman <mik

Re: [MTT devel] GSOC application

Hello Ethan, On Mon, Apr 13, 2009 at 5:44 PM, Ethan Mallove wrote: > > Will this translate to something like > lib/MTT/Reporter/GoogleDatabase.pm? If we are to move away from the > current MTT Postgres database, we want to be able to submit results to > both the current

Re: [MTT devel] GSOC application

On Tue, Apr 14, 2009 at 5:04 PM, Jeff Squyres <jsquy...@cisco.com> wrote: > On Apr 13, 2009, at 2:08 PM, Mike Dubman wrote: > > Hello Ethan, >> > > Sorry for joining the discussion late... I was on travel last week and that > always makes me waaay behind on my I

Re: [MTT devel] GSOC application

On Tue, Apr 14, 2009 at 11:50 PM, Ethan Mallove <ethan.mall...@sun.com>wrote: > On Tue, Apr/14/2009 09:27:14PM, Mike Dubman wrote: > >On Tue, Apr 14, 2009 at 5:04 PM, Jeff Squyres <jsquy...@cisco.com> > wrote: > > > > On Apr 13, 2009, at 2:08 PM, Mik

Re: [MTT devel] GSOC application

On Wed, Apr 15, 2009 at 3:51 AM, Jeff Squyres <jsquy...@cisco.com> wrote: > On Apr 14, 2009, at 2:27 PM, Mike Dubman wrote: > > Ah, good point (python/java not perl). But I think that >> lib/MTT/Reporter/GoogleDataStore.pm could still be a good thing -- we have >> in

Re: [MTT devel] GSOC application

On Wed, Apr 15, 2009 at 5:23 PM, Jeff Squyres <jsquy...@cisco.com> wrote: > On Apr 15, 2009, at 9:14 AM, Mike Dubman wrote: > > Hmm. Ok, so you're saying that we define a "phase object" (for each >> phase) with all the fields that we expect to have, but if we n

Re: [MTT devel] GSOC application

On Wed, Apr 15, 2009 at 8:50 PM, Jeff Squyres <jsquy...@cisco.com> wrote: > On Apr 15, 2009, at 1:45 PM, Mike Dubman wrote: > > yep. correct. We can define only static attributes (which we know for sure >> should present in every object of given type and leave phase s

Re: [MTT devel] GSOC application

I will prepare ppt with summary of what were discussed and agreed, milestones, open questions and other thoughts. regards Mike On Thu, Apr 16, 2009 at 2:07 PM, Jeff Squyres wrote: > Ok, I think we converged on a time: 9am US Eastern / 4pm Israel next > Thuesday, April 23. >

Re: [MTT devel] GSOC application

t; (no need to be formal; if slides help, great, otherwise don't make slides > just because we have webex available) > > > > On Apr 16, 2009, at 9:50 AM, Mike Dubman wrote: > > I will prepare ppt with summary of what were discussed and agreed, >> milestones, open questions and

Re: [MTT devel] [MTT svn] svn:mtt-svn r1306

Hey Jeff, This code acts as a pre-processor during loading of ini file into mtt. It replaces builtin vars %VAR% with their values, for example: ... [Test run: trivial] my_sect_name=%INI_SECTION_NAME% ... %INI_SECTION_NAME% get replaced with real value. (trivial) it is useful in the following

Re: [MTT devel] [MTT svn] svn:mtt-svn r1314

Hey Eytan, It seems argv is participating in the following scenarios: 1. argv should be defined in mtt.ini for every single [Test Run] section 2. Currently, _argv() is returing un-evaluated argv`s value 3. _argv() is usually part of "exec=" parameter line of [MPI Details], which is evaluated

Re: [MTT devel] [MTT svn] svn:mtt-svn r1319

On Fri, Sep 25, 2009 at 10:08 PM, Jeff Squyres <jsquy...@cisco.com> wrote: > On Sep 24, 2009, at 12:46 PM, Mike Dubman wrote: > > Im not familiar with :\n semantics, how does it force Bourne shell and >> what it actually does :)? (seems like leftovers from 1960) >>

Re: [MTT devel] [MTT svn] svn:mtt-svn r1320

it seems it can be retired. executable() covers more cases. shell() can be the alias of executable() for backwards compatibility. Also, DoCommand::CmdScript should be changed to DoCommand::Cmd inside executable() to really cover more cases. regards Mike On Tue, Sep 29, 2009 at 8:35 PM, Ethan

[MTT devel] mtt not working on sles 11up2 perl 5.10.0

Hello guys, mtt fails on sles11up2 with perl version 5.10.0 but works on other distros as a charm. The same minimalistic ini file which works on other distro`s fails on sles with error: >> Test Run [osu] >> Running with [open mpi] / [1.3.3] / [openmpi] Using MPI Details [open mpi] with MPI

Re: [MTT devel] questions about MTT database from HDF

Hi, Also, there is an MTT option to select Google Datastore as a storage backend for mtt results. Pro: - your data is stored in the Google`s cloud - You can access your data from scripts - You can create a custom UI for you data visualization - You can use Google`s default datastore querying

[MTT devel] mtt questions

Hi, Do you know if there is mtt option to stop mtt execution if job`s failure ratio succeeds specified value, something like: [mtt] stop_on_test_failures=1% Also, are there any ini files examples/successes of how to use mtt with non-MPI based applications? Thanks Mike

Re: [MTT devel] [MTT svn] svn:mtt-svn r1481 - in trunk: client lib/MTT/Reporter

0 PM, Jeff Squyres <jsquy...@cisco.com> wrote: > Mike -- > > MongoDB is a NoSQL thingy, right? > > Can you describe this plugin a bit? Do you guys have some kind of > reporter for MongoDB? > > > On Aug 1, 2012, at 5:46 AM, <svn-commit-mai...@open-mpi.org> wrote: &g

Re: [MTT devel] mtt-relay patch - create pid file when run as daemon

/var/run is only writable to root, but script uses it explicitly. maybe it is worse to add fallback if non-root user starts mtt-relay. On Mon, Sep 30, 2013 at 2:08 PM, Christoph Niethammer wrote: > Hello, > > As on many systems init scripts and the handling of services is

Re: [MTT devel] [MTT svn] svn:mtt-svn r1637 - trunk/lib/MTT/Values/Functions/MPI

ould be a > LOT of output. > > > On Apr 5, 2014, at 7:27 PM, <svn-commit-mai...@open-mpi.org> wrote: > > > Author: miked (Mike Dubman) > > Date: 2014-04-05 19:27:28 EDT (Sat, 05 Apr 2014) > > New Revision: 1637 > > URL: https://svn.open-mpi.org/trac/mtt/chan

Re: [MTT devel] [MTT svn] svn:mtt-svn r1637 - trunk/lib/MTT/Values/Functions/MPI

ry* verbose, and is generally only > useful when something goes wrong. > > I run Cisco's automated MTT with only --verbose. > > > > On Apr 7, 2014, at 6:35 PM, Mike Dubman <mi...@dev.mellanox.co.il> wrote: > > > ohh.. it is just flooding the log with same data for every test

Re: [MTT devel] [MTT svn] GIT: MTT branch master updated. 016088f2a0831b32ab5fd6f60f4cabe67e92e594

ths, at a minimum. > > > > > On Jun 23, 2014, at 4:37 AM, Mike Dubman <mi...@dev.mellanox.co.il> wrote: > > > this commit does more harm then good. > > we experience following: > > > > - some child processes still running after timeout a

Re: [MTT devel] [MTT svn] GIT: MTT branch master updated. 016088f2a0831b32ab5fd6f60f4cabe67e92e594

(jsquyres) <jsquy...@cisco.com > wrote: > On Jun 23, 2014, at 7:47 AM, Mike Dubman <mi...@dev.mellanox.co.il> wrote: > > > after patch, it killed child processes but kept mpirun ... itself. > > What does that mean -- are you saying that mpirun is still running? Was > m

Re: [OMPI devel] trunk not compiling for btl_openib_connect_oob.c

sorry about that, we find a better way to resolve it later. fix commited. On Wed, Mar 16, 2011 at 6:00 PM, Jeff Squyres wrote: > Ya, you're right -- I'm looking at my MTT right now and I see lots of > broken installs. > > But it works if I compile manually. Weird. > >

Re: [OMPI devel] openib error for message size 1.5 GB

Please try with "--mca mpi_leave_pinned 0" On Mon, Jun 6, 2011 at 4:16 PM, Sebastian Rinke wrote: > Dear all, > > While trying to send a message of size 1610612736 B (1.5 GB), I get the > following error: > >

[OMPI devel] RFC: extend MTL API

WHAT: Adding communicator add/delete callbacks to MTL. WHY: MTL will be able to separate messages on different contexts. WHEN: On trunk (later on v1.5 as well), Tuesday telconf, 5 July 2011 TIMEOUT: Tuesday telconf, 12 July 2011 DETAILS: Currently MTLs do no handle communicator contexts in

Re: [OMPI devel] MXM question

yes, it is for Infiniband only If OMPI was compiled with mxm support - it will be always selected. (same selection logic as for other MTL components) It should be explicitly disabled to fall back into PML. On Tue, Aug 2, 2011 at 10:29 PM, Jeff Squyres wrote: > Is MXM for

[OMPI devel] Invalid free (btl_openib_endpoint.c, 448) in v1.5

Hi guys, The latest v1.5 from trunk, compiled in debug mode yields following error with openib. The quick blame leads to the following commit: r25616 | bosilca | 2011-12-10 00:18:16 +0200 (Sat, 10 Dec 2011) | 4 lines Fixes #2930: CMR: memcpy() w/overlapping addresses in btl_openib_connect_oob.c

Re: [OMPI devel] Invalid free (btl_openib_endpoint.c, 448) in v1.5

after removing my debug prints - the correct line is 448 On Mon, Dec 12, 2011 at 7:46 PM, Mike Dubman <mike.o...@gmail.com> wrote: > > > Hi guys, > > The latest v1.5 from trunk, compiled in debug mode yields following error > with openib. > The quick blame le

Re: [OMPI devel] Invalid free (btl_openib_endpoint.c, 448) in v1.5

nope On Mon, Dec 12, 2011 at 10:40 PM, George Bosilca <bosi...@eecs.utk.edu>wrote: > Do we have the same issue in the trunk? > > george. > > On Dec 12, 2011, at 12:49 , Mike Dubman wrote: > > after removing my debug prints - the correct line is 448 > > On M

Re: [OMPI devel] Invalid free (btl_openib_endpoint.c, 448) in v1.5

ed soon. > > Thanks for the report, > george. > > On Dec 13, 2011, at 00:25 , Mike Dubman wrote: > > nope > > On Mon, Dec 12, 2011 at 10:40 PM, George Bosilca <bosi...@eecs.utk.edu>wrote: > >> Do we have the same issue in the trunk? >> >> george. &g

Re: [OMPI devel] [EXTERNAL] Re: r26255 has made openib unusable on Solaris platforms

Too many drama - we will fix it to detect hooks availability at configure stage, this will make your life back to normal. The problem is not a Mellanox hw, but Intel PCI bus implementation, which charge extra latency if buffers are not aligned. The patch is a workaround for this problem and help

[OMPI devel] 1.6.x compilation failure with intel compiler

Hi, ompi 1.6.x - compilation fails with intel compiler, but works with gcc. compiler version: 10.1.026 Regards CXX otfaux.o CXX Control.o CXX Handler.o CXX State.o CXXLD otfaux ../../otflib/.libs/libotf.so: undefined reference to `inflateReset' ../../otflib/.libs/libotf.so: undefined

Re: [OMPI devel] OMPI 1.6 affinity fixes: PLEASE TEST

Not good: /labhome/alexm/workspace/openmpi-1.6.1a1hge06c2f2a0859/inst/bin/mpirun --host h-qa-017,h-qa-017,h-qa-017,h-qa-017,h-qa-018,h-qa-018,h-qa-018,h-qa-018 -np 8 --bind-to-core -bynode -display-map /usr/mpi/gcc/mlnx-openmpi-1.6rc4/tests/osu_benchmarks-3.1.1/osu_alltoall

Re: [OMPI devel] OMPI 1.6 affinity fixes: PLEASE TEST

attached. On Wed, May 30, 2012 at 2:32 PM, Jeff Squyres wrote: > On May 30, 2012, at 7:20 AM, Jeff Squyres wrote: > > >> $hwloc-ls --of console > >> Machine (32GB) > >> NUMANode L#0 (P#0 16GB) + Socket L#0 + L3 L#0 (20MB) + L2 L#0 (256KB) > + L1 L#0 (32KB) + Core L#0 > >>

Re: [OMPI devel] OMPI 1.6 affinity fixes: PLEASE TEST

. > > The error message was correct - there are not enough cores on those nodes > to do what you requested. > > > On May 30, 2012, at 6:19 AM, Mike Dubman wrote: > > attached. > > On Wed, May 30, 2012 at 2:32 PM, Jeff Squyres <jsquy...@cisco.com> wrote: &

Re: [OMPI devel] OMPI 1.6 affinity fixes: PLEASE TEST

1, core id=0), with > hyperthreading (siblings=2). So lstopo looks good. > E5-2650 is supposed to have 8 cores. I assume you use Linux > cgroups/cpusets to restrict the available cores. The missconfiguration may > be there. > Brice > > > > > Le 30/05/2012 15:14, Mike

Re: [OMPI devel] OMPI 1.6 affinity fixes: PLEASE TEST

no cgroups or cpusets. On Wed, May 30, 2012 at 4:59 PM, Jeff Squyres <jsquy...@cisco.com> wrote: > On May 30, 2012, at 9:47 AM, Mike Dubman wrote: > > > ohh.. you are right, false alarm :) sorry siblings != cores - so it is HT > > OMPI 1.6.soon-to-be-1 should han

Re: [OMPI devel] RFC: OMPI git mirror on github.com

btw, once it is at github, it can be the only repo with multiple access interfaces: svn,git https://github.com/blog/1178-collaborating-on-github-with-subversion Finally, we can commit from git or svn w/o keeping r/o mirrors for hg/git . What do you think? On Fri, Aug 17, 2012 at 2:07 PM,

Re: [OMPI devel] RFC: OMPI git mirror on github.com

re item (5): The current svn tree can be set as read-only and serve as a reference for old commit numbers. It is rarery used anyway to search through historic commit numbers and can be done in read-only historic tree. All other items can use svn interface of guthub and stay w/o any change. It

Re: [OMPI devel] [EXTERNAL] glibc malloc hooks going away

ubuntu12 fedora16 the hooks are there, but marked as "deprecated" On Tue, Jun 11, 2013 at 4:05 AM, Jeff Squyres (jsquyres) wrote: > On Jun 10, 2013, at 10:29 AM, "Barrett, Brian W" > wrote: > > > At least they've finally come to that conclusion. I

Re: [OMPI devel] [EXTERNAL] glibc malloc hooks going away

yes On Tue, Jun 11, 2013 at 5:10 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com > wrote: > On Jun 11, 2013, at 9:37 AM, Mike Dubman <mi...@dev.mellanox.co.il> wrote: > > > ubuntu12 > > fedora16 > > > > the hooks are there, but marked as &q

Re: [OMPI devel] more oshmem issues

Hi, Sorry about that. the fix is here: r29223 Regards M On Fri, Sep 20, 2013 at 7:32 PM, Jeff Squyres (jsquyres) wrote: > Mellanox -- > > Please remove all uses of bzero. memset is the portable way to go here. > > > > On Sep 20, 2013, at 12:30 PM, "David Goodell

Re: [OMPI devel] oshmem 32 bit compile failures

Hi, the code passes compilation with gcc/icc 32bit toolkits. We don`t have absoft fortran compiler in the lab, is there any way we can have it to try? Igor has some wild guess about what problem can be and created patch (attached). Could you try to apply it on OMPI tree and check with absoft

Re: [OMPI devel] 32 bit build breakage in oshmem

Hi Jeff, I`m unable to reproduce this fail with gcc and -m32 flags. I added same command line to jenkins (and in jenkins we trust) - and it passed on RHEL 6.4 with stock gcc. Please check that you run it on latest trunk and please provide a gcc version if it is not a stock one. Thanks M On

Re: [OMPI devel] More oshmem compile errors

Hi, We have icc test in jenkins and it passes. What icc version do you use and exact command line to configure? Is it latest trunk? Thanks M On Tue, Oct 8, 2013 at 5:37 PM, Jeff Squyres (jsquyres) wrote: > With icc, getting errors about pointer math with (void*) types. See

Re: [OMPI devel] [EXTERNAL] Re: shmem vs. oshmem

Thanks Brian, The code in trunk already generates: oshccoshfort oshmem_info oshrun On Sat, Oct 26, 2013 at 12:13 AM, Barrett, Brian W wrote: > i thought I mentioned this before, but the compilers should be oshcc, > oshCC, and oshfort, with the starter named

Re: [OMPI devel] [EXTERNAL] Re: shmem vs. oshmem

cc (and friends). I didn't notice the osh* versions in my > >initial post. > > > >The question still remains, though -- do we still want these names > >installed: > > > >- > >$ cd $prefix/bin > >$ ls -1 shmem* > >shmemcc@ > >shm

Re: [OMPI devel] [EXTERNAL] Re: shmem vs. oshmem

, which does not seem like good development practice. > Or, put it another way, one of the 1.7 Release Managers can't see a reason > that we should bring shmemcc and friends into 1.7, so convince me. > > Brian > > On 10/28/13 1:08 PM, "Mike Dubman" <mi...@dev.mellanox.co.

Re: [OMPI devel] SHMEM v1.7 merge proposal

Hi, This is exactly the way we handle it now. We have internal branch on top of v1.7 with all SHMEM code in it. It runs mtt and other tests. Once we done with all changes - we will provide patch (and branch direct access if needed) for GK. Kind Regards Mike. On Tue, Oct 29, 2013 at 1:02 AM,

Re: [OMPI devel] SHMEM v1.7 merge proposal

will it be ok, that once all is ready, we push git2svn branch for this? On Tue, Oct 29, 2013 at 12:35 PM, Jeff Squyres (jsquyres) < jsquy...@cisco.com> wrote: > I think Brian's point is that it should be a SVN branch. > > > On Oct 29, 2013, at 3:27 AM, Mike Dubman <mi.

Re: [OMPI devel] [EXTERNAL] Re: SHMEM v1.7 merge proposal

29, 2013 04:36 AM Mountain Standard Time > *To: *Open MPI Developers > *Subject: *[EXTERNAL] Re: [OMPI devel] SHMEM v1.7 merge proposal > > > > > I think Brian's point is that it should be a SVN branch. > > > On Oct 29, 2013, at 3:27 AM, Mike Dubman <mi...@dev

Re: [OMPI devel] SHMEM v1.7 merge proposal

"svn merge" and friends. -Dave On Oct 29, 2013, at 6:08 AM, Mike Dubman <mi...@dev.mellanox.co.il> wrote: > will it be ok, that once all is ready, we push git2svn branch for this? > > > On Tue, Oct 29, 2013 at 12:35 PM, Jeff Squyres (jsquyres) < jsquy...@cisco.com> wrot

[OMPI devel] v1.7 is broken

Hi, The latest merges from trunk to v1.7 broke v1.7 for openib: *08:08:36* btl_openib_xrc.c:80: warning: 'ibv_close_xrc_domain' is deprecated (declared at /usr/include/infiniband/ofa_verbs.h:102)*08:08:36* CC btl_openib_fd.lo*08:08:36* CC btl_openib_ip.lo*08:08:36* CC

Re: [OMPI devel] debian/ directory

unfortunately, debian/ packaging works only if located in rootDir. :( If you have better ones - can you put it and we will use it? On Wed, Nov 6, 2013 at 4:38 PM, Sylvestre Ledru wrote: > Hello, > > Le 06/11/2013 15:26, Barrett, Brian W a écrit : > > Hi all - > > > > Mike

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r29615 - in trunk: . contrib contrib/dist/linux debian debian/source

ussion before committing... > > Also, how does this compare to the existing Open MPI Debian package? Have > you talked to its maintainer? Are you replacing it? > > > > > > On Nov 6, 2013, at 4:50 AM, svn-commit-mai...@open-mpi.org wrote: > > > Author: miked (Mike

Re: [OMPI devel] [OMPI svn] svn:open-mpi r29615 - in trunk: . contrib contrib/dist/linux debian debian/source

; as a step in your build script? Top level names > are (somewhat) precious and should not be added casually. > > -Dave > > On Nov 6, 2013, at 4:50 AM, svn-commit-mai...@open-mpi.org wrote: > > > Author: miked (Mike Dubman) > > Date: 2013-11-06 07:50:28 EST (Wed, 06

Re: [OMPI devel] [OMPI svn] svn:open-mpi r29633 - in trunk: . contrib contrib/dist/linux contrib/dist/linux/debian contrib/dist/linux/debian/source

sorry, I though it was mentioned: motivation is to build .deb OMPI package as part of debian/ubuntu ofed distribution. (similar logic/rationale as buildrpm.sh which is part of OMPI) On Thu, Nov 7, 2013 at 8:15 PM, Jeff Squyres (jsquyres) wrote: > On Nov 7, 2013, at 9:10 AM,

Re: [OMPI devel] [OMPI svn] svn:open-mpi r29633 - in trunk: . contrib contrib/dist/linux contrib/dist/linux/debian contrib/dist/linux/debian/source

it is for MOFED now and probably OFED later. will rename to contrib/dist/mofed tomorrow. Thanks On Thu, Nov 7, 2013 at 9:08 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com>wrote: > On Nov 7, 2013, at 10:21 AM, Mike Dubman <mi...@dev.mellanox.co.il> wrote: > > > sorry, I

Re: [OMPI devel] [OMPI svn] svn:open-mpi r29733 - in trunk: config oshmem

disable > oshmem. Please revert this. > > Thanks > Ralph > > > On Nov 22, 2013, at 5:51 AM, svn-commit-mai...@open-mpi.org wrote: > > > Author: miked (Mike Dubman) > > Date: 2013-11-22 08:51:46 EST (Fri, 22 Nov 2013) > > New Revision: 29733 > > URL

Re: [OMPI devel] [EXTERNAL] Re: [OMPI svn] svn:open-mpi r29733 - in trunk: config oshmem

is how > we disable a project, not by adding a big fixed around a makefile (see > ORTE). > > Brian > > > > Sent with Good (www.good.com) > > > -Original Message- > *From: *Mike Dubman [mi...@dev.mellanox.co.il] > *Sent: *Saturday, November 23, 2013 0

  1   2   >