[OMPI devel] Paul's testing summary

This is an attempt to summarize the status of the trunk and 1.7.4rc with respect to my testing. There are 6 issues that to the best of my knowledge have not yet been conclusively closed. There might still be others buried in my sea of test results. 1. opal/util/path.c See thread beginning with

Re: [OMPI devel] trunk build failure on {Free,Net,Open}BSD

Jeff and I iterated a bit off-list and opal/util/path.c in tonight's trunk tarball (1.9a1r30255) works for all of my systems. With the help of Jeff's recently-enhanced test/util/opal_path_nfs.c I was able to verify that NFS mounts are now correctly identified on the *BSD systems (and still correct

Re: [OMPI devel] trunk - ibverbs configure error on Solaris-11

FYI: still present in tonight's trunk tarball (1.9a1r30255). Don't know if was expected to be fixed or not. -Paul On Thu, Jan 9, 2014 at 2:24 PM, Paul Hargrove wrote: > Jeff, > > The requested config.log was attached > as

Re: [OMPI devel] trunk - build failure on OpenBSD

Appears to be fixed in tonight's trunk tarball (1.9a1r30255). Thanks, -Paul On Fri, Jan 10, 2014 at 7:03 AM, Jeff Squyres (jsquyres) wrote: > This looks like how we handled this issue elsewhere in the OMPI code base, > too. > > Mellanox: in the interest of getting another

[hwloc-devel] Create success (hwloc git dev-34-g5198d4c)

Creating nightly hwloc snapshot git tarball was a success. Snapshot: hwloc dev-34-g5198d4c Start time: Fri Jan 10 21:01:01 EST 2014 End time: Fri Jan 10 21:03:36 EST 2014 Your friendly daemon, Cyrador

Re: [OMPI devel] 1.7.4rc2r30168 - PGI F08 failure

Yes, I'm pretty sure we've seen that before, and it was ID'ed as either a local configuration issue or a PGI bug. On Jan 10, 2014, at 7:51 PM, Paul Hargrove wrote: > > > > On Fri, Jan 10, 2014 at 4:46 PM, Paul Hargrove wrote: > > On Fri, Jan 10,

Re: [OMPI devel] 1.7.4rc2r30168 - PGI F08 failure

On Fri, Jan 10, 2014 at 4:46 PM, Paul Hargrove wrote: > > On Fri, Jan 10, 2014 at 4:43 PM, Jeff Squyres (jsquyres) < > jsquy...@cisco.com> wrote: > >> Don't worry about PGI 11. I'm happy enough knowing that PGI 12 works. > > > Test is already running to satisfy my own

Re: [OMPI devel] 1.7.4rc2r30168 - PGI F08 failure

On Fri, Jan 10, 2014 at 4:43 PM, Jeff Squyres (jsquyres) wrote: > Don't worry about PGI 11. I'm happy enough knowing that PGI 12 works. Test is already running to satisfy my own curiosity. But I'll only post the result if something fails. -Paul -- Paul H. Hargrove

Re: [OMPI devel] 1.7.4rc2r30168 - PGI F08 failure

Don't worry about PGI 11. I'm happy enough knowing that PGI 12 works. On Jan 10, 2014, at 6:59 PM, Paul Hargrove wrote: > Jeff, > > I said earlier that PGI *12* has build mpi_f08 correctly in response to Larry > baker asking about 11 and 12. > I don't have a PGI 11 config

Re: [OMPI devel] 1.7.4rc2r30168 - PGI F08 failure

Jeff, I said earlier that PGI *12* has build mpi_f08 correctly in response to Larry baker asking about 11 and 12. I don't have a PGI 11 config on my list at the moment, but would be surprised if I can't find one. I will look for a PGI 11, but am focused on the opal_path_nfs() stuff at the moment.

Re: [OMPI devel] 1.7.4rc2r30168 - PGI F08 failure

On Jan 10, 2014, at 6:45 PM, Paul Hargrove wrote: > Keep in mind that I have no specific reason to think pgi-10 should be > accepted for building mpi_f08. > My only observation was that it seemed to be rejected w/ less configure > testing than was applied to accept 8.0 and

Re: [OMPI devel] 1.7.4rc2r30168 - PGI F08 failure

On Fri, Jan 10, 2014 at 3:33 PM, Jeff Squyres (jsquyres) wrote: > Can you send the output from pgi-10? We don't reject based on compiler > name/version -- it should be all behavior-based checks... Attached. Keep in mind that I have no specific reason to think pgi-10

Re: [OMPI devel] 1.7.4rc2r30168 - PGI F08 failure

On Jan 10, 2014, at 1:26 PM, Paul Hargrove wrote: > OMPI's configure says pgi-8.0 and pgi-9.0 are "good". > But pgi-10.0 is rejected without even subjecting it to the tests. > This situation (8.0 and 9.0 "better" than 10.0) sounds fishy to me. That's true. Can you send the

Re: [OMPI devel] 1.7.4rc2r30168 - odd run failure

I *believe* oob can now support virtual interfaces, but can't swear to it - only very lightly tested on my box. I'll mark this in for resolving in 1.7.5 On Jan 10, 2014, at 1:55 PM, Paul Hargrove wrote: > Ralph, > > Since this turned out to be a matter of an unsupported

[OMPI devel] NUMA bug in openib BTL device selection

I believe I found a bug in openib BTL and just want to see if folks agree with this. When we are running on a NUMA node and we are bound to a CPU, we only ant to use the IB device that is closest to us. However, I observed that we always used both devices regardless. I believe there is a bug

Re: [OMPI devel] 1.7.4rc2r30168 - odd run failure

Ralph, Since this turned out to be a matter of an unsupported system configuration, it is my opinion that this doesn't need to be addressed for 1.7.4 if it would cause any further delay. Also, I noticed this system has lo and lo:0. I know the TCP BTL doesn't support virtual interfaces (trac

Re: [OMPI devel] [EXTERNAL] Re: 1.7.4rc2r30168 - configure failure on Mac OSX 10.5

Agreed, let's drop 10.5. I don't want to fix that bug given it's likely customer base... Brian Sent with Good (www.good.com) -Original Message- From: Ralph Castain [r...@open-mpi.org] Sent: Friday, January 10, 2014 08:14 AM Mountain Standard Time To: Open

Re: [OMPI devel] [EXTERNAL] Re: MX and PSM in 1.7.4

I'm not actually sure about MX. I was testing, but since the last release our machine has been retired. So it's possible we're missing coverage there. Brian Sent with Good (www.good.com) -Original Message- From: Ralph Castain [r...@open-mpi.org] Sent:

Re: [OMPI devel] 1.7.4rc2r30168 - odd run failure

On Jan 10, 2014, at 12:59 PM, Paul Hargrove wrote: > Ralph, > > This is the front end of a production cluster at NERSC. > So, I would not be surprised if there is a fairly restrictive firewall > configuration in place. > However, I could't find a way to query the

Re: [OMPI devel] 1.7.4rc2r30168 - odd run failure

Ralph, This is the front end of a production cluster at NERSC. So, I would not be surprised if there is a fairly restrictive firewall configuration in place. However, I could't find a way to query the configuration. The verbose output with (only) "-mca oob_base_verbose 10" is attached. On a

Re: [OMPI devel] callback debugging

On Jan 10, 2014, at 12:45 PM, Adrian Reber wrote: > On Fri, Jan 10, 2014 at 09:48:14AM -0800, Ralph Castain wrote: >> >> On Jan 10, 2014, at 8:02 AM, Adrian Reber wrote: >> >>> I am currently trying to understand how callbacks are working. Right now >>> I am

Re: [OMPI devel] callback debugging

On Fri, Jan 10, 2014 at 09:48:14AM -0800, Ralph Castain wrote: > > On Jan 10, 2014, at 8:02 AM, Adrian Reber wrote: > > > I am currently trying to understand how callbacks are working. Right now > > I am looking at orte/mca/rml/base/rml_base_receive.c > >

Re: [OMPI devel] 1.7.4rc2r30168 - odd run failure

Bingo - the proc can't send a message to the daemon to tell it "i'm alive and need my nidmap data". I suspect we'll find that your headnode isn't allowing us to open a socket for communication between two processes on it, and we don't have (yet) a pipe-like mechanism to replace it. Can verify

Re: [OMPI devel] 1.7.4rc2r30168 - odd run failure

Ralph, Configuring using a proper --with-tm=... I find that I *can* run a singleton in an allocation ("qsub -I -l nodes=1 "). The case of a singleton on the front end is still failing. The verbose output using "-mca state_base_verbose 5 -mca plm_base_verbose 5 -mca odls_base_verbose 5" is

Re: [OMPI devel] 1.7.4rc2r30168 - odd run failure

On Fri, Jan 10, 2014 at 12:12 PM, Ralph Castain wrote: > Out of curiosity, if you do have an allocation on run on it, does it work? > This is a TORQUE-managed cluster and configure didn't find TM headers/libs. So, I didn't even consider trying inside an allocation. I will

Re: [OMPI devel] 1.7.4rc2r30168 - odd run failure

On Jan 10, 2014, at 11:04 AM, Paul Hargrove wrote: > 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,

Re: [OMPI devel] Paul H build on Solaris

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

Re: [OMPI devel] 1.7.4rc2r30168 - odd run failure

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

Re: [OMPI devel] 1.7.4rc2r30168 - odd run failure

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

Re: [OMPI devel] 1.7.4rc2r30168 - PGI F08 failure

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

Re: [OMPI devel] 1.7.4rc2r30168 - odd run failure

??? that was it? Was this built with --enable-debug? On Jan 10, 2014, at 10:03 AM, Paul Hargrove wrote: > > > > On Fri, Jan 10, 2014 at 7:12 AM, Ralph Castain wrote: > Very strange. Try adding "-mca grpcomm_base_verbose 5 -mca > orte_nidmap_verbose

Re: [OMPI devel] 1.7.4rc2r30168 - odd run failure

On Fri, Jan 10, 2014 at 7:12 AM, Ralph Castain wrote: > Very strange. Try adding "-mca grpcomm_base_verbose 5 -mca > orte_nidmap_verbose 10" to your cmd line with the trunk version and let's > see what may be happening > Most of my systems don't have new enough autotools to

Re: [OMPI devel] callback debugging

On Jan 10, 2014, at 8:02 AM, Adrian Reber wrote: > I am currently trying to understand how callbacks are working. Right now > I am looking at orte/mca/rml/base/rml_base_receive.c > orte_rml_base_comm_start() which does > >orte_rml.recv_buffer_nb(ORTE_NAME_WILDCARD, >

Re: [hwloc-devel] Use of

Sweet; thanks. On Jan 10, 2014, at 12:25 PM, Brice Goglin wrote: > Looks like we're good. > Brice > > > > Le 10/01/2014 18:05, Jeff Squyres (jsquyres) a écrit : >> K, will do. >> >> On Jan 10, 2014, at 12:00 PM, Brice Goglin >> wrote: >> >>>

Re: [hwloc-devel] Use of

Looks like we're good. Brice Le 10/01/2014 18:05, Jeff Squyres (jsquyres) a écrit : > K, will do. > > On Jan 10, 2014, at 12:00 PM, Brice Goglin > wrote: > >> Push it to master, we'll what regression testing at >> https://ci.inria.fr/hwloc/job/master-1-check/ thinks

Re: [OMPI devel] 1.7.4rc2r30168 - misc harmless *BSD warnings

Fixed all of these except: - pushed hwloc fix upstream and waiting for equivalent of hwloc MTT testing to see how it fares - we try not to edit ROMIO since it comes from upstream (i.e., we tolerate warnings in there) On Jan 9, 2014, at 3:48 AM, Paul Hargrove wrote: >

Re: [hwloc-devel] Use of

K, will do. On Jan 10, 2014, at 12:00 PM, Brice Goglin wrote: > Push it to master, we'll what regression testing at > https://ci.inria.fr/hwloc/job/master-1-check/ thinks about it > Brice > > > > "Jeff Squyres (jsquyres)" a écrit : > Brice /

Re: [OMPI devel] RFC: OB1 optimizations

Looks like it slowed down by about 20ns from the original patch. That is to be expected when latencies are this low. Results for the following are attached: - Trunk r30215 sm and vader results for osu_latency. - Trunk r30215 + patch take3 for both sm and vader. - Trunk r30215 + patch + forced

Re: [OMPI devel] hcoll destruction via MPI attribute

On Jan 10, 2014, at 10:57 AM, George Bosilca wrote: > This is not the same example as before. This example is correct, it does not > rely on the send being eagerly completed. I know. :-) Just to tie up this thread for the web archives: >> My point (which I guess I

[hwloc-devel] Use of

Brice / Samuel -- In http://www.open-mpi.org/community/lists/devel/2014/01/13619.php, Paul Hargrove found this compiler warning: - On OpenBSD the header malloc.h exists, but is NOT intended to be used: -bash-4.2$ grep -B2 'is obsolete' make.log CC bind.lo In file included from

Re: [OMPI devel] 1.7.4rc2r30168 - PGI F08 failure

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 is the type(*), dimension(..) notation, which no fortran compiler

Re: [OMPI devel] 1.7.4rc2r30168 - usnic warning w/ icc

Fixed; thanks. On Jan 9, 2014, at 8:27 PM, Paul Hargrove wrote: > > 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

[OMPI devel] 1.7.4

Hi folks If you've been following all the email on this list, you know that we are still working on resolving portability issues with 1.7.4. We obviously will not meet our milestone of releasing it today :-( I'm hoping the delay will only last a week, and thus won't impact 1.7.5 too much. The

Re: [OMPI devel] shared lib version on trunk

Il 1/10/2014 3:50 PM, Jeff Squyres (jsquyres) ha scritto: On Jan 10, 2014, at 9:48 AM, marco atzeri <> wrote: building openmpi-1.9a1r30128-1, I notice - # Version information for libmpi. current=0 age=0 revision=0 -- while on

Re: [OMPI devel] hcoll destruction via MPI attribute

On Jan 10, 2014, at 10:04 AM, George Bosilca wrote: >> MPI Comm comm; >> // comm is setup as an hcoll-enabled communicator >> if (rank == x) { >> MPI_Send(..., y, tag, MPI_COMM_WORLD); >> MPI_Comm_free(comm); >> } else if (rank == y) { >> MPI_Comm_free(comm); >>

Re: [OMPI devel] 1.7.4rc2r30168 - configure failure on Mac OSX 10.5

And we do appreciate your breakage! :-) I think we'll just drop 10.5 from the list as that's very old and likely not worth fixing On Jan 9, 2014, at 4:50 PM, Paul Hargrove wrote: > Ralph, > > I can build fine on 10.7 (the system I am typing on now), and on 10.6 too. > >

Re: [OMPI devel] 1.7.4rc2r30168 - odd run failure

Very strange. Try adding "-mca grpcomm_base_verbose 5 -mca orte_nidmap_verbose 10" to your cmd line with the trunk version and let's see what may be happening Any chance of library confusion here? On Jan 9, 2014, at 9:57 PM, Paul Hargrove wrote: > The problem is seen with

Re: [OMPI devel] hcoll destruction via MPI attribute

On Jan 10, 2014, at 15:55 , Jeff Squyres (jsquyres) wrote: > On Jan 10, 2014, at 9:49 AM, George Bosilca wrote: > >> As I said, this is the case today. There are ongoing discussion in the MPI >> Forum to relax the wording of the MPI_Comm_free as most

Re: [OMPI devel] trunk - build failure on OpenBSD

This looks like how we handled this issue elsewhere in the OMPI code base, too. Mellanox: in the interest of getting another good tarball today, since it's the weekend for you, I'll apply this patch. (thanks Paul!) On Jan 10, 2014, at 2:20 AM, Paul Hargrove wrote: >

Re: [OMPI devel] hcoll destruction via MPI attribute

On Jan 10, 2014, at 9:49 AM, George Bosilca wrote: > As I said, this is the case today. There are ongoing discussion in the MPI > Forum to relax the wording of the MPI_Comm_free as most of the MPI > implementations do not rely on the strict “collective” behavior of the >

Re: [OMPI devel] shared lib version on trunk

On Jan 10, 2014, at 9:48 AM, marco atzeri wrote: > building openmpi-1.9a1r30128-1, I notice > - > # Version information for libmpi. > current=0 > age=0 > revision=0 > -- > > while on 1.7.3 is >

Re: [OMPI devel] hcoll destruction via MPI attribute

On Jan 10, 2014, at 15:31 , Jeff Squyres (jsquyres) wrote: > On Jan 10, 2014, at 9:19 AM, George Bosilca wrote: > >> However, one should keep in mind that MPI_Comm_free does not have to be a >> collective function, thus making any type of collective

[OMPI devel] shared lib version on trunk

building openmpi-1.9a1r30128-1, I notice - # Version information for libmpi. current=0 age=0 revision=0 -- while on 1.7.3 is -- # Version information for libmpi. current=3 age=2 revision=0

Re: [OMPI devel] trunk build failure on {Free,Net,Open}BSD

On Jan 10, 2014, at 9:18 AM, "Jeff Squyres (jsquyres)" wrote: >> It seems to indicate that even if one does find a statfs() function, there >> are multiple os-dependent versions and it should therefore be avoided. >> Since statvfs() is defined by POSIX, it should be

Re: [OMPI devel] hcoll destruction via MPI attribute

On Jan 10, 2014, at 9:19 AM, George Bosilca wrote: > However, one should keep in mind that MPI_Comm_free does not have to be a > collective function, thus making any type of collective > assumption/communications inside the attribute destructor might lead to > deadlocks

Re: [OMPI devel] hcoll destruction via MPI attribute

On Jan 10, 2014, at 14:50 , Jeff Squyres (jsquyres) wrote: > On Jan 9, 2014, at 12:05 PM, Joshua Ladd wrote: > >> [Josh] We have a recursive doubling algorithm in progress implemented with >> PML send/recvs, more accurately , with

Re: [OMPI devel] trunk build failure on {Free,Net,Open}BSD

On Jan 9, 2014, at 11:00 PM, Paul Hargrove wrote: > The following might be helpful: > > http://stackoverflow.com/questions/1653163/difference-between-statvfs-and-statfs-system-calls > > It seems to indicate that even if one does find a statfs() function, there > are

Re: [OMPI devel] hcoll destruction via MPI attribute

On Jan 9, 2014, at 12:05 PM, Joshua Ladd wrote: > [Josh] We have a recursive doubling algorithm in progress implemented with > PML send/recvs, more accurately , with "RTE_isend/RTE_irecv" functions, > which, in the case of OMPI are PML calls. Does that mean that you'll

[OMPI devel] README / OS X versions (was: 1.7.4rc2r30168 - configure failure on Mac OSX 10.5)

For my own sanity: 10.9: Mavericks, last release Dec 2013 10.8: Mountain Lion, last release Oct 2013 (maybe not dead) 10.7: Lion, last release Oct 2012 (dead) 10.6: Snow Leopard, last release 2011 (dead) 10.5: Leopard, last release 2009 (dead) I don't think we should expend any effort for 10.5;

Re: [OMPI devel] RFC: OB1 optimizations

Nathan, When you get access to the machine it might be interesting to show not only the after-patch performance but also what the trunk is getting on the same architecture. George. On Jan 8, 2014, at 18:09 , Nathan Hjelm wrote: > Yeah. Its hard to say what the results

Re: [OMPI devel] 1.7.4rc2r30148 run failure NetBSD6-x86

Hey Paul, Thanks for report, we will commit fix shortly. M On Fri, Jan 10, 2014 at 7:20 AM, Paul Hargrove wrote: > > 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

Re: [OMPI devel] trunk build failure on {Free,Net,Open}BSD

Il 1/10/2014 5:00 AM, Paul Hargrove ha scritto: The following might be helpful: http://stackoverflow.com/questions/1653163/difference-between-statvfs-and-statfs-system-calls It seems to indicate that even if one does find a statfs() function, there are multiple os-dependent versions and it

Re: [OMPI devel] trunk - build failure on OpenBSD

Based on how MAP_ANONYMOUS vs MAP_ANON is dealt with in opal/mca/memory/linux/malloc.c, I believe the patch below is an appropriate solution for this issue. Additionally, it handles the possibility that MAP_FAILED is not defined (not sure where that comes up, but opal/mca/memory/linux/malloc.c

Re: [OMPI devel] 1.7.4rc2r30168 - odd run failure

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. > > >

Re: [OMPI devel] 1.7.4rc2r30168 - odd run failure

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

Re: [OMPI devel] 1.7.4rc2r30148 run failure NetBSD6-x86

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

Re: [OMPI devel] uDAPL and elan in 1.7.4?

Corrected - thanks! On Jan 9, 2014, at 5:40 PM, Paul Hargrove wrote: > 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

Re: [OMPI devel] Portals vs Portals4 in 1.7.4

Corrected - thanks! On Jan 9, 2014, at 5:45 PM, Paul Hargrove wrote: > 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

Re: [OMPI devel] 1.7.4rc2r30148 run failure NetBSD6-x86

Really have to thank you for your persistence, Paul. Truly appreciated. Glad to hear you can run ring_c. I'm going to let Jeff handle the path.c and ANON issue as those are both configury things he was working today. Not sure why the shmem fortran examples would try to build - will pass that

Re: [OMPI devel] 1.7.4rc2r30168 - odd run failure

It's missing the hostname from the other process - should have been included in the data passed into each proc at startup, which is why it's so puzzling. On Jan 9, 2014, at 8:56 PM, Paul Hargrove wrote: > Ralph, > > The problem has occurred with two builds (both PGI-based)

Re: [OMPI devel] 1.7.4rc2r30148 run failure NetBSD6-x86

Ralph, My NetBSD builds fail on the new opal/util/path.c, but by adding #undef HAVE_STATFS near the top of path.c I can get past that. Next I hit the MAP_ANON-vs-MAP_ANONYMOUS issue and fixed that manually. Next I hit the attempt to build shmem fortran examples despite the lack of a fortran