On Thu, May 2, 2013 at 5:55 AM, Jeff Squyres (jsquyres)
wrote:
> Given that we know there are compile bugs with XRC in all the v1.7
> releases so far (which seems to show how few people are actually using
> XRC...), there are definitely "growing pains", as Ralph mentioned.
Jeff may be a little
Ralph,
I am not an expert, by any means, but based on a presentation I heard 4
hours ago:
The Xeon and Phi instruction sets have a large intersection, but neither is
a subset of the other.
In particular, Phi has its own SIMD instructions *instead* of Xeon's MMX,
SSEn, etc.
There is also on CMPXCH
know exactly what that means (I haven't read their docs about this stuff),
> but I suspect that it's more than just launching MPI processes on them...
>
>
> On May 2, 2013, at 8:54 PM, Paul Hargrove wrote:
>
> > Ralph,
> >
> > I am not an expert, by any means, b
Let me jump in here with a different perspective.
First, for those who don't know me:
+ I am NOT an OMPI developer
+ I am NOT an MPI application author either
+ I am a developer of "competing" HPC communications software (GASNet)
+ I contribute to OMPI mainly by building release candidates
I don't know it if just me, but the logo appears to have gotten cropped on
the 2.25" button and the round magnet.
-Paul
On Fri, Oct 18, 2013 at 12:41 PM, Jeff Squyres (jsquyres) <
jsquy...@cisco.com> wrote:
> OMPI Developer Community --
>
> Per the upcoming 10th anniversary of OMPI's SVN r1 (an
Still looks the same to me, even after changing browsers.
Screen shot attached.
-Paul
On Fri, Oct 18, 2013 at 1:59 PM, Jeff Squyres (jsquyres) wrote:
> Fixed!
>
> On Oct 18, 2013, at 3:44 PM, Paul Hargrove
> wrote:
>
> > I don't know it if just me, but the l
On Fri, Oct 25, 2013 at 2:32 PM, Jeff Squyres (jsquyres) wrote:
> We're shipping oshmem, not shmem, so why not call them oshmem examples
> [that also happen to be shmem examples] -- rather than shmem examples [that
> also happen to be oshmem examples]?
My USD 0.02:
If the examples were written
Jeff,
If this approach is to be adopted by other components (and perhaps other
MPIs), then it would be important for the enumeration variable name to be
derived in a UNIFORM way:
__SOMETHING
Without a fixed value for "SOMETHING" somebody will need to read sources
(or documentation) to make the
On Tue, Nov 5, 2013 at 6:00 PM, Jeff Squyres (jsquyres)
wrote:
> On Nov 5, 2013, at 2:54 PM, Paul Hargrove wrote:
>
> > If this approach is to be adopted by other components (and perhaps other
> MPIs), then it would be important for the enumeration variable name to be
> derive
gt;
> How about using a * in the name, to represent where the match is? E.G.,
> btl_usnic_*_enum?
>
> It's a string, so it's not just limited to letters and underscores.
>
> Sent from my phone. No type good.
>
> On Nov 5, 2013, at 6:26 PM, "Paul Hargrove&quo
On Dec 4, 2013 12:07 PM, "Jeff Squyres (jsquyres)"
wrote:
[...]
> But in some ways, having uncompilable code is a *good* thing, because it
tells you exactly where you need to work on the architecture. Just
updating it to *compile* removes that safeguard -- will you
remember/re-find all those plac
I see the failure below when building 1.7.4rc1 on FreeBSD-9 (amd64).
It looks to be just a missing header, probably sys/stat.h.
$ gcc --version
gcc (GCC) 4.2.1 20070831 patched [FreeBSD]
Only configure option passed was --prefix-...
-Paul
Making all in mca/sharedfp/sm
CC sharedfp_sm.l
When building 1.7.4rc1 on OpenBSD-5 and NetBSD-6 (both amd64) I see what
appears to be the same three errors ("make" output at end of this email)
on both platforms.
All three syntax errors appears to be collisions on the symbol if_mtu:
-bash-4.2$ cat -n openmpi-1.7.4rc1/opal/util/if.h | grep -w
In 1.7.4rc1's README support is still claimed for Solaris 11 on x86_64 with
Sun Studio (12.2 and 12.3):
- Oracle Solaris 10 and 11, 32 and 64 bit (SPARC, i386, x86_64),
with Oracle Solaris Studio 12.2 and 12.3
However, I get a build failure when configured with:
CC=cc CFLAGS=-m64 --w
o] Error 1
make[2]: Leaving directory
`/shared/OMPI/openmpi-1.7.4rc1-solaris11-x64-ib-gcc452/BLD/opal/mca/if/posix_ipv4
-Paul
On Thu, Dec 19, 2013 at 3:51 PM, Paul Hargrove wrote:
> In 1.7.4rc1's README support is still claimed for Solaris 11 on x86_64
> with Sun Studio (12.2 and 1
ifr) < 0) {
> -opal_output(0, "btl_usnic_opal_ifinit: ioctl(SIOCGIFMTU)
> failed with errno=%d", errno);
> -break;
> -}
> -intf->if_mtu = ifr->ifr_mtu;
> +/* get the MTU */
> + if (ioctl(sd, SIOCGIFMTU, ifr) < 0)
recursive')
The getrlimit manpage on this platform does not list RLIMIT_AS.
Running "grep -rl RLIMIT_AS /usr/include" confirms that this constant does
not exist.
So, I think "#ifdef RLIMIT_AS" is required.
-Paul
On Thu, Dec 19, 2013 at 4:39 PM, Jeff Squyres (jsquyres) wrote:
nic btl on Solaris at all.
Perhaps just because the OFED stack is present?
-Paul
On Thu, Dec 19, 2013 at 4:39 PM, Jeff Squyres (jsquyres) wrote:
> Try http://www.open-mpi.org/~jsquyres/unofficial/.
>
> Should have both "if" fixes in it.
>
>
> On Dec 19, 2013, at 7
Testing with Solaris 10 on SPARC, I was expecting to encounter the bus
error reported previously by Siegman Gross. Instead I see the following
hwloc-related abort:
$ env
PATH=/home/hargrove/OMPI/openmpi-1.7.4rc1-solaris10-sparcT2-ss12u3-v9/INST/bin:$PATH
LD_LIBRARY_PATH_64=/home/hargrove/OMPI/o
52/openmpi-1.7.4rc2forpaul/ompi/mca/btl/usnic/btl_usnic_util.h:19:45:
error: static declaration of �fls� follows non-static declaration
/usr/include/string.h:87:12: note: previous declaration of �fls� was here
make[2]: *** [btl_usnic_module.lo] Error 1
-Paul
On Thu, Dec 19, 2013 at 6:35 PM, Pau
Attached is the output from "make install" of 1.7.4rc1 + Jeff's fix for the
symbol conflict on "if_mtu".
There appear to be at least 2 issues.
1) There are lots of (not fatal) messages about ldconfig not existing, but
according to he NetBSD lists that utility went away with the conversion
from a.
e:
> I believe this one has already been fixed and is in the nightly (1.7.4rc2)
> - for now, you can just set "--bind-to none" on the cmd line to get past it
>
>
> On Dec 19, 2013, at 6:42 PM, Paul Hargrove wrote:
>
> Testing with Solaris 10 on SPARC, I was e
Probably nobody cares, but I'll report this for completeness.
In trying to understand the "make install" failure on NetBSD-6 I run
"autogen.sh".
The versions detected:
Searching for autoconf
Found autoconf version 2.69; checking version...
Found version component 2 -- need 2
Dec 19, 2013 at 6:47 PM, Paul Hargrove wrote:
> Jeff,
>
> I didn't actually get very far after fixing __always_inline.
> In fact, the build still fails on the *same* line, but for a different
> (valid) reason:
> fls() is declared in /usr/include/string.h
>
>
Manually #ifdef'ing out the RLIMIT_AS code which lead to my previous
failure on OpenBSD-5 allows me to reach the (sigh) *next* problem:
Making all in mpi/cxx
CXX mpicxx.lo
/home/phargrov/OMPI/openmpi-1.7.4rc2forpaul-openbsd5-amd64/openmpi-1.7.4rc2forpaul/ompi/mpi/cxx/mpicxx.cc:120:21:
error
ems where I reported
issues on Thu night.
On Thu, Dec 19, 2013 at 7:19 PM, Ralph Castain wrote:
> I believe this one has already been fixed and is in the nightly (1.7.4rc2)
> - for now, you can just set "--bind-to none" on the cmd line to get past it
>
>
> On Dec 19, 2013,
e just went in
> today. Jeff has since regenerated the tarball for the web site, so the one
> up there should have most (if not all) of these problems fixed
>
> Have a great holiday!
> Ralph
>
>
> On Dec 20, 2013, at 11:40 AM, Paul Hargrove wrote:
>
> Ralph,
>
> I
This email is a summary of my results testing 1.7.4rc2r30031.
I will send detailed follow-ups on the new issues.
So, this is a heads-up to let you know this version still has significant
problems for me.
FreeBSD-9/amd64
+ "mpirun -np 2 examples/ring_c" hangs!
+ "mpirun -np 1 examples/ring_c" runs
With plenty of help from Jeff and Ralph's bug fixes in the past 24 hours, I
can now build OMPI for NetBSD. However, running even a simple example
fails:
Having set PATH and LD_LIBARY_PATH:
$ mpirun -np 1 examples/ring_c
just hangs
Output from "top" shows idle procs:
PID USERNAME PRI NICE SIZE
I have a build of OMPI 1.7.4rc2r30031 on FreeBSD-9 finally.
I can (as I will detail in another email) run only singletons at the moment.
However, when I do I get a warning that is, IMHO, unnecessary:
$ mpirun -np 1 examples/ring_c
---
t; Paul -
>
> Any chance you could grab a stack trace from the mpi app? That's probably
> the fastest next step
>
> Brian
>
>
>
> Sent with Good (www.good.com)
>
>
> -Original Message-
> *From: *Paul Hargrove [phhargr...@lbl.gov]
> *Sent: *Fr
This case is not quite like my OpenBSD-5 report.
On FreeBSD-9 I *can* run singletons, but "-np 2" hangs.
The following hangs:
$ mpirun -np 2 examples/ring_c
The following complains about the "bogus" btl selection.
So this is not the same as my problem with OpenBSD-5:
$ mpirun -mca btl bogus -np 2
c000
On Fri, Dec 20, 2013 at 2:48 PM, Paul Hargrove wrote:
> Brian,
>
> Of course, I should have thought of that myself.
> See below for backtrace from a singleton run.
>
> I'm starting an --enable-debug build to maybe get some line number info
> too.
>
> -Paul
&
On Fri, Dec 20, 2013 at 3:12 PM, Dave Goodell (dgoodell) wrote:
> On Dec 20, 2013, at 4:43 PM, Paul Hargrove wrote:
>
> > The warning is correct that no such interface exists.
> > However 127.0.0.1/24 DOES exist:
> >
> > $ ifconfig lo0 inet
> >
, 2013 at 2:59 PM, Paul Hargrove wrote:
> This case is not quite like my OpenBSD-5 report.
> On FreeBSD-9 I *can* run singletons, but "-np 2" hangs.
>
> The following hangs:
> $ mpirun -np 2 examples/ring_c
>
> The following complains about the "bogus" btl s
FWIW:
I've confirmed that this is REGRESSION relative to 1.7.3, which works fine
on FreeBSD-9
-Paul
On Fri, Dec 20, 2013 at 3:30 PM, Paul Hargrove wrote:
> And the FreeBSD backtraces again, this time configured with --enable-debug
> and for all threads:
>
> The 100%-c
16 PM, Paul Hargrove wrote:
> Below is the backtrace again, this time configured w/ --enable-debug and
> for all threads.
> -Paul
>
> Thread 2 (thread 1021110):
> #0 0x1bc0ef6c5e3a in nanosleep () at :2
> #1 0x1bc0f317c2d4 in nanosleep (rqtp=0x7f7bc900, rmtp=
try back-porting the fix(es) to see if 1.7.3 works or not .
>
> -Paul
>
>
> On Fri, Dec 20, 2013 at 3:16 PM, Paul Hargrove wrote:
>
>> Below is the backtrace again, this time configured w/ --enable-debug and
>> for all threads.
>> -Paul
>>
>> T
On Fri, Dec 20, 2013 at 4:02 PM, Paul Hargrove wrote:
> FWIW:
> I've confirmed that this is REGRESSION relative to 1.7.2, which works fine
> on OpenBSD-5
>
> I could not build 1.7.3 due to some of issues fixed for 1.7.4rc in the
> past 24 hours.
> I am going to try b
vestigating and think I
> know where the issue might lie (a timer that is firing to indicate a failed
> connection attempt and causing a race condition)
>
>
> On Dec 20, 2013, at 4:02 PM, Paul Hargrove wrote:
>
> FWIW:
> I've confirmed that this is REGRESSION relative t
utogen.pl if I can find
time.
However, I am sending this email to document my finding in case I don't get
back to this.
-Paul
On Fri, Dec 20, 2013 at 6:49 AM, Jeff Squyres (jsquyres) wrote:
> I just submitted a CMR to Brian to fix this:
>
> https://svn.open-mpi.org/trac/
;
+
open(OUT, ">configure.patched") || my_die "Can't open
configure.patched";
print OUT $c;
close(OUT);
-Paul
On Fri, Dec 20, 2013 at 6:04 PM, Paul Hargrove wrote:
> As I indicated earlier today, the CMRed fix to push/pop "dir" in hwloc did
I get a warning from the current 1.7.4rc2r30076:
--
WARNING: No preset parameters were found for the device that Open MPI
detected:
Local host:pcp-j-20
Device name: mthca0
Device vendor ID: 0
Interestingly enough the 4MB latency actually improved significantly
relative to the initial numbers.
-Paul [Sent from my phone]
On Jan 8, 2014 8:50 AM, "George Bosilca" wrote:
> These results are way worst that the one you send on your previous email?
> What is the reason?
>
> George.
>
> On
Nevermind, since Nathan just clarified that the results are not comparable.
-Paul [Sent from my phone]
On Jan 8, 2014 8:58 AM, "Paul Hargrove" wrote:
> Interestingly enough the 4MB latency actually improved significantly
> relative to the initial numbers.
>
> -Paul [Sent f
When I compile the current 1.7.4rc on NetBSD with no configure arguments, I
still get the "make install" failure that I have detailed in previous
emails.
HOWEVER, if I configure with "--enable-static --disable-shared" then I get
an earlier failure at build time (partial "make V=1" output shown bel
While I have yet to get a working build on NetBSD for x86-64 h/w, I *have*
successfully built Open MPI's current 1.7.4rc tarball on NetBSD-6 for x86.
However, I can't *run* anything:
Attempting the ring_c example on 2 cores:
-bash-4.2$ mpirun -mca btl sm,self -np 2 examples/ring_c
---
Note the following still indicates that "--bind-to none" is the default:
-bash-4.2$ mpirun --help | grep -A2 'bind-to '
--bind-to Policy for binding processes [none (default) |
hwthread | core | socket | numa | board] (supported
qualifiers
s given for btl_tcp_if_exclude. This
value will be ignored.
Local host: pcp-j-17
Value: 127.0.0.1/8
Message:Did not find interface matching this subnet
--
-Paul
> On Dec 20, 2013, at 3:20 PM, Paul Hargrove wrote:
>
This partial make output shows a build failure of the current trunk tarball
on FreeBSD-9/x86-64:
CC path.lo
/home/phargrov/OMPI/openmpi-trunk-freebsd9-amd64/openmpi-1.9a1r30146/opal/util/path.c:
In function 'opal_path_df':
/home/phargrov/OMPI/openmpi-trunk-freebsd9-amd64/openmpi-1.9a1r30146
When trying to configure the OMPI trunk on a Solaris-11/x86-64 with
--enable-openib, I see the following error not seen with the 1.7 branch:
*** Compiler flags
checking which of CFLAGS are ok for debugger modules... -DNDEBUG -m64 -mt
checking for debugger extra CFLAGS... -g
checking for the C com
As of 1.7.4rc2r30148 there appears to be a missing "#include "
in bcol_basesmuma_smcm.c. Both the Solaris Studio compiler (output below)
and gcc agree on this point.
CC bcol_basesmuma_smcm.lo
"/shared/OMPI/openmpi-1.7-latest-solaris11-x64-ib-ss12u3/openmpi-1.7.4rc2r30148/ompi/mca/bcol/bas
I am still testing the current 1.7.4rc tarball on my various systems. The
latest failure (shown below) is a SEGV somewhere below MPI_Init on a old,
but otherwise fairly normal, Linux/x86 (32-bit) system.
$ /home/pcp1/phargrov/OMPI/openmpi-1.7-latest-linux-x86/INST/bin/mpirun -np
1 examples/ring_c
bad backing store site - any chance you could
> give me a line number from this? There are a lot of calls to register
> params in that code and I'd need some help in figuring out which one wasn't
> right.
>
>
> On Jan 8, 2014, at 6:59 PM, Paul Hargrove wrote:
>
r, I'm
> mindful of all the things you need to do, so please only if you have the
> time.
>
> Thanks
> Ralph
>
> On Jan 8, 2014, at 8:23 PM, Paul Hargrove wrote:
>
> Ralph,
>
> Building with gcc-4.1.2 fixed the problem for me. I also removed an old
> install o
t;.
>
> So I just changed it to an "else" statement in the trunk and scheduled it
> for 1.7.4 if it passes muster - see how this works for you.
>
> Ralph
>
>
> On Jan 8, 2014, at 4:52 PM, Paul Hargrove wrote:
>
> This partial make output shows a build failure
gt; Hmmm...I see the problem. Looks like binding isn't supported on that
> system for some reason, so we need to turn "off" our auto-binding when we
> hit that condition. I'll check to see why that isn't happening (was
> supposed to do so)
>
>
> On Jan 8,
No joy running autogen.pl on my FreeBSD system.
So, I'll try to remember to run on Thu night's trunk tarball.
-Paul
On Wed, Jan 8, 2014 at 9:01 PM, Paul Hargrove wrote:
> Ralph,
>
> *IF* I have new enough autotools to autogen on my FreeBSD platform, I'll
> take
, argv=0xbfe04114) at ring_c.c:19
On Wed, Jan 8, 2014 at 8:45 PM, Paul Hargrove wrote:
> Only takes <30 seconds of typing to start the test and I get email when it
> is done.
> Typing these emails takes more of my time than the actual testing does.
>
> -Paul
>
>
> On W
all the systems for the latter actually is intended to amount to "anything
> else".
>
> So I just changed it to an "else" statement in the trunk and scheduled it
> for 1.7.4 if it passes muster - see how this works for you.
>
> Ralph
>
>
> On Jan 8, 2014
With Ralph's fix for opal/util/path.c, I can build the trunk on
FreeBSD-9/x86-64.
However, building the examples fails with:
$ cp -r $SRCDIR/examples .
$ cd examples
$ make
mpicc -g hello_c.c -o hello_c
mpicc -g ring_c.c -o ring_c
mpicc -g connectivity_c.c -o connectivity_c
shmemcc -g -o he
Building the trunk on FreeBSD-9/x86-64, and using gmake to work around the
non-portable examples/Makefile, I *still* encounter issues with shmemfort
when running "gmake" in the examples subdirectory:
$ gmake
mpicc -ghello_c.c -o hello_c
mpicc -gring_c.c -o ring_c
mpicc -gconnectivi
Yup, the 1.7.4rc2r30168 tarball appears to have resolved this.
-Paul
On Wed, Jan 8, 2014 at 4:08 PM, Ralph Castain wrote:
> Yeah - it only today was approved for move into 1.7.4 :-)
>
> Hopefully will make it into tonight's tarball
>
>
> On Jan 8, 2014, at 3:58 P
Some minor misc warnings from the current 1.7.4rc tarball:
On both FreeBSD and NetBSD, the symbol CACHE_LINE_SIZE used
in ompi/mca/bcol/basesmuma/ appears to clash with a system-defined symbol.
FreeBSD-9/x86-64:
CC bcol_basesmuma_component.lo
In file included from
/home/phargrov/OMPI/openm
The following three warnings occur on 32-bit targets, and can each be
avoided by adding an intermediate cast to uintptr_t or intptr_t:
-bash-4.2$ grep -B2 'different size' make.log
CC fcoll_dynamic_file_read_all.lo
/home/phargrov/OMPI/openmpi-1.7-latest-netbsd6-i386/openmpi-1.7.4rc2r30168/
size
-Paul
On Thu, Jan 9, 2014 at 1:07 AM, Paul Hargrove wrote:
> The following three warnings occur on 32-bit targets, and can each be
> avoided by adding an intermediate cast to uintptr_t or intptr_t:
>
> -bash-4.2$ grep -B2 'different size
is topology, only "pu's", so
> "bind-to core" is going to fail even though binding is supported. Will
> adjust.
>
> Thanks!
>
> On Jan 8, 2014, at 9:06 PM, Paul Hargrove wrote:
>
> Requested verbose output below.
> -Paul
>
> -bash-4.2$ mpir
Jeff,
I actually noted this in the unofficial tarball you rolled for me in
December:
On Thu, Dec 19, 2013 at 6:35 PM, Paul Hargrove wrote:
[...]
> I'm not sure why one is trying to build the usnic btl on Solaris at all.
> Perhaps just because the OFED stack is present?
>
[...]
Jeff,
The changes as described in the commit message make good sense to me except
for one thing:
In the 1.7 branch there is still a defined(__WINDOWS__) case for which
opal_path_nfs() is currently a no-op . So, I fear that if CMR'ed blindly
both the configure-time and build-time checks to ensure
as to do something with our handling of the legacy
> --with-openib switch...? (it's been deprecated on the trunk in favor of
> --with-verbs)
>
>
> On Jan 8, 2014, at 8:38 PM, Paul Hargrove wrote:
>
> > When trying to configure the OMPI trunk on a Solaris-11/x86-64
On Thu, Jan 9, 2014 at 2:08 PM, Paul Hargrove wrote:
> However, only my Solaris (10/SPARC and 11/x86-64) systems have NFS-mounted
> filesystems. So, I don't have any means to ensure that the "newly active"
> code performs correctly on the BSD systems. In other words,
The README in the latest 1.7.4rc lists support for:
- OS X (10.5, 10.6, 10.7), 32 and 64 bit (x86_64), with gcc and
Absoft compilers (*)
Should 10.8 (Mountain Lion) be listed?
What about 10.9 (Mavericks)?
I can test 10.5 through 10.8 but haven't been doing so assuming that is
covered by th
As I noted in another email, 1.7.4's README claims support for Mac OSX
versions 10.5 through 10.7. So, I just now tried (but failed) to build on
10.5 (Leopard):
*** Assembler
checking dependency style of gcc -std=gnu99... gcc3
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -p
On Thu, Jan 9, 2014 at 4:15 PM, Jeff Squyres (jsquyres)
wrote:
> For example, if you build and run the test like this:
>
> make check
> ./opal_path_nfs . Makefile ~
>
> It'll report if ., Makefile, and ~ are on network filesystems (i.e., the
> result of sending each of ".", "Makefile", and "your_h
My attempts to build the current 1.7.4rc tarball with versions 8.0 and 9.0
of the Portland Group compilers fails miserably on compilation of
mpi-f08-types.F90.
I am sort of surprised by the attempt to build Fortran 2008 support w/ such
old compilers.
I think that fact itself is the real bug here,
nno if we really go back that far, Paul - I doubt anyone has tested on
> anything less than 10.8, frankly. Might be better if we update to not make
> claims that far back.
>
> Were you able to build/run on 10.7?
>
> On Jan 9, 2014, at 3:25 PM, Paul Hargrove wrote:
>
> As I no
Trying to run on the front-end of one of our production Linux systems I see
the following:
$ mpirun -mca btl sm,self -np 2 examples/ring_c'
[cvrsvc01:17692] [[42051,1],0] ORTE_ERROR_LOG: Data for specified key not
found in file
/global/homes/h/hargrove/GSCRATCH/OMPI/openmpi-1.7-latest-linux-x86_64
V11.x, V12.x, ..., all being parsed as V1.
> My recollection is that some C++ code was affected.
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov
>
>
>
> On 9 Jan 2014, at 4:35 PM, Paul Hargrove wrote:
>
> My attempts to build the current 1
I believe the following means that the compiler has determined that the two
named variables DO NOT actually get initialized to NULL as written.
However, it looks like their initialization is not required, as each is
set before it is read.
CC btl_usnic_component.lo
/scratch/scratchdirs/har
The README in the current 1.7.4rc tarball still claims support for uDAPL
and Quadrics Elan. Unless I am mistaken, those were both removed.
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
Computer and Data Sciences Department Tel: +1-510-495-2352
Lawr
The README in the current 1.7.4rc tarball lists support for "Portals" and
documents --with-portals{,-config,-libs} configure arguments.
However, unless I am mistaken mtl:portals is gone and mtl:portals4 has
different configure arguments.
-Paul
--
Paul H. Hargrove phharg
Is anybody still testing MX and PSM?
They are both still present in ompi/mca/mtl/
I have access to a system w/ QLogic HCAs w/ PSM and have verified that I
can:
$ mpirun -mca btl sm,self -np 2 -host n15,n16 -mca mtl psm examples/ring_c
I have an x86 (32-bit) system w/ MX headers and libs that I ha
ation because of the batch system detected
at configure time. However, I would have expected a more informative error
message for that case.
-Paul
On Thu, Jan 9, 2014 at 5:03 PM, Paul Hargrove wrote:
> Trying to run on the front-end of one of our production Linux systems I
> see th
Jeff,
Sorry, but the new opal/util/pth.c in the trunk tarball (1.9a1r30215) fails
to build on NetBSD:
CC path.lo
/home/phargrov/OMPI/openmpi-trunk-netbsd6-i386/openmpi-1.9a1r30215/opal/util/path.c:
In function 'opal_path_nfs':
/home/phargrov/OMPI/openmpi-trunk-netbsd6-i386/openmpi-1.9a1r3
With the new opal/util/path.c I get farther building the trunk on OpenBSD
but hit a new failure:
Making all in mca/memheap
CC base/memheap_base_frame.lo
CC base/memheap_base_select.lo
CC base/memheap_base_alloc.lo
/home/phargrov/OMPI/openmpi-trunk-openbsd5-i386/openmpi-1.9a
Jeff,
No joy on Solaris-10 either:
CC path.lo
"/home/hargrove/OMPI/openmpi-trunk-solaris10-sparcT2-ss12u3-v8plus/openmpi-1.9a1r30215/opal/util/path.c",
line
478: prototype mismatch: 2 args passed, 4 expected
"/home/hargrove/OMPI/openmpi-trunk-solaris10-sparcT2-ss12u3-v8plus/openmpi-1.9a1
On Thu, Jan 9, 2014 at 7:15 PM, Paul Hargrove wrote:
> My Solaris-11 build stopped again on the failure to find ibv_open_device().
> I am re-running w/o --enable-openib now.
>
It finished while I was typing the previous message.
The Solaris-11 build failed in the same way as Solaris-1
, if one does want to keep the
current logic (or at least something similar) it looks like configure
should not assume statfs() is available without *also* confirming that
"struct statfs" is available.
-Paul
On Thu, Jan 9, 2014 at 7:18 PM, Paul Hargrove wrote:
>
> On Thu, Jan
Same issue for NetBSD, too.
-Paul
On Thu, Jan 9, 2014 at 7:09 PM, Paul Hargrove wrote:
> With the new opal/util/path.c I get farther building the trunk on OpenBSD
> but hit a new failure:
>
> Making all in mca/memheap
> CC base/memheap_base_frame.lo
&g
; of a slurm cluster.
>
> Only possibly relevant thing I see is that this was built with PGI - any
> chance you could try a gcc based build? All my tests are done with gcc, so
> I'm wondering if PGI is the source of the trouble here.
>
>
> On Jan 9, 2014, at 6:17 PM,
compiler.
I *was* able to finally confirm that I can now run ring_c.
-Paul
On Thu, Jan 9, 2014 at 12:07 PM, Paul Hargrove wrote:
> Ralph,
>
> Thanks for fielding all these issues I've been finding.
> I will plan to run tonight's trunk tarball through all of the systems
On Thu, Jan 9, 2014 at 9:05 PM, Ralph Castain wrote:
> Not sure why the shmem fortran examples would try to build - will pass
> that off to Jeff as well (sorry Jeff!)
This is the issue I described in
http://www.open-mpi.org/community/lists/devel/2014/01/13616.php
It seems that oshmem_info alwa
On Thu, Jan 9, 2014 at 8:56 PM, Paul Hargrove wrote:
> I'll try a gcc-based build on one of the systems ASAP.
Sorry, Ralph: the failure remains when built w/ gcc.
Let me know what to try next and I'll give it a shot.
-Paul
--
Paul H. Hargrove phhar
The problem is seen with both the trunk and the 1.7.4rc tarball.
-Paul
On Thu, Jan 9, 2014 at 9:23 PM, Paul Hargrove wrote:
>
> On Thu, Jan 9, 2014 at 8:56 PM, Paul Hargrove wrote:
>
>> I'll try a gcc-based build on one of the systems ASAP.
>
>
> Sorry, Ralph: t
ROT_READ | PROT_WRITE,
MAP_SHARED |
-#if defined (__APPLE__)
-MAP_ANON |
-#elif defined (__GNUC__)
-MAP_ANONYMOUS |
+#ifdef MAP_ANONYMOUS
+MAP_ANONYMOUS |
#endif
MAP_FIXED,
0,
On Thu, Jan 9, 2014 at 8:35 PM, Paul Hargrov
libs from
old OMPI builds.
-Paul
>
> On Jan 9, 2014, at 9:57 PM, Paul Hargrove wrote:
>
> The problem is seen with both the trunk and the 1.7.4rc tarball.
>
> -Paul
>
>
> On Thu, Jan 9, 2014 at 9:23 PM, Paul Hargrove wrote:
>
>>
>> On Thu, Jan 9, 20
On Fri, Jan 10, 2014 at 7:49 AM, Jeff Squyres (jsquyres) wrote:
> Paul --
>
> The output from configure looks ok to me. We're testing for the various
> capabilities of the fortran compiler that we need, most of which have been
> around for quite a while. One Big New Thing that isn't around yet
On Fri, Jan 10, 2014 at 10:08 AM, Ralph Castain wrote:
> ??? that was it? Was this built with --enable-debug?
Nope, I missed --enable-debug. Will try again.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
Computer and Data Sciences Department
On Fri, Jan 10, 2014 at 10:41 AM, Paul Hargrove wrote:
>
> On Fri, Jan 10, 2014 at 10:08 AM, Ralph Castain wrote:
>
>> ??? that was it? Was this built with --enable-debug?
>
>
> Nope, I missed --enable-debug. Will try again.
>
>
OK, Take-2 below.
There is an ob
On Thu, Jan 9, 2014 at 12:35 PM, Jeff Squyres (jsquyres) wrote:
> Thanks. We're just going to change the test in the usnic BTL to be
> explicit about only building on 64 bit Linux.
>
Last night's trunk did NOT try to build btl:usnic on Solaris.
So, this issue looks to be resolved in trunk.
-Pa
101 - 200 of 925 matches
Mail list logo
