1
1
Граф коммитов

8107 Коммитов

Автор SHA1 Сообщение Дата
Ralph Castain
59d6f1e2eb Remove ompi_ignores on gridengine components as this seems resolved - thanks Pak for quick response!
Fixed a few very minor compiler complaints in the pls_gridengine_module.c file. ISO C is less forgiving about where variables get declared.

This commit was SVN r11156.
2006-08-11 15:32:17 +00:00
Pak Lui
99a0521e44 * Fix the issue that Ralph observed in MacOS X with an invalid header file
and other warnings.

This commit was SVN r11155.
2006-08-11 15:04:51 +00:00
Ralph Castain
5fd6306c2f Add ompi_ignores until the configuration can be fixed
This commit was SVN r11154.
2006-08-11 14:11:41 +00:00
Pak Lui
08352878cc * Added in new ras and pls components to support Sun N1 Grid Engine (N1GE)
6 and its open source version as the job launchers for ORTE.

This commit was SVN r11153.
2006-08-10 21:46:52 +00:00
Rolf vandeVaart
726e92e3c5 Create some simple examples of how to use DTrace
with Open MPI.  Sill need to finalize on the
Makefile so this gets included in distribution.

Reviewed by: Jeff Squyres

This commit was SVN r11151.
2006-08-10 20:09:19 +00:00
Brian Barrett
20b8a2a6ae - Make script x86_64 aware
- increase initial disk image size to deal with the extra file metadata
  due to now having 4 builds

This commit was SVN r11146.
2006-08-10 15:08:11 +00:00
Terry Dontje
67980d7f97 Removed include of stdbool.h since it was not being used and was causing the
Sun compilers to abort when make check was done.

This commit was SVN r11145.
2006-08-10 14:25:45 +00:00
Ralph Castain
ec3eeb819d Remove unused variable to make Cyrador happy.
This commit was SVN r11144.
2006-08-10 12:57:55 +00:00
Ralph Castain
62e70e6b3a Enable the use of "prefix" for comm_spawn child processes. With this patch:
1. comm_spawn processes by default will inherit the "--prefix" from their parent job. Thus, the "--prefix" provided on the command line will be propagated automatically to any children.

2. application programs can override the default by providing their own "ompi_prefix" in the MPI_Info parameter passed to comm_spawn

This commit was SVN r11143.
2006-08-09 20:48:51 +00:00
Ralph Castain
bd937b219d Tell xcast not to send to processes that have "aborted".
One of those fixes that has been sitting on another branch for awhile...sigh.

This commit was SVN r11142.
2006-08-09 18:23:43 +00:00
Ralph Castain
56c15963af Finalize the session directory and runtime when the orted exits due to a failed launch.
This commit was SVN r11141.
2006-08-09 17:00:53 +00:00
Ralph Castain
8496b6aff4 When a "fork" launch cannot find the executable, the system used to just return an error. This meant that the state of that process was never updated in the registry, leaving the counters at the incorrect levels. As a result, the triggers would never fire to indicate that the job had been aborted. This left orterun and other orteds/processes hanging.
This fix should fix the problem. I will test it on a broader range of systems forsooth...

This commit was SVN r11140.
2006-08-09 15:29:08 +00:00
Ralph Castain
ddd575d126 Ensure that the localhost gets placed on the registry with the same name as found in the system_info structure. Otherwise, we wind up with confusion in the session directory names.
This commit was SVN r11139.
2006-08-09 15:26:37 +00:00
Ralph Castain
0f7ebe5f8b Fix a few properties to ignore the usual culprits
This commit was SVN r11138.
2006-08-09 15:25:47 +00:00
Jeff Squyres
1057120057 Arrgh - missing ":" in the output (to make it like the others).
This commit was SVN r11137.
2006-08-08 21:35:38 +00:00
Jeff Squyres
0757dfba42 A few more cleanups
This commit was SVN r11135.
2006-08-08 19:43:21 +00:00
Donald Kerr
f50aad2721 making basic udapl btl available by removing the .ompi_ignore and .ompi_unignore files
This commit was SVN r11134.
2006-08-08 19:19:54 +00:00
Galen Shipman
f7015abb92 set the inline_max to something.. doh..
This commit was SVN r11133.
2006-08-08 17:24:12 +00:00
Galen Shipman
c93711cfdb checking for max_inline_data == 0 as an error condition is not valid,, so
don't do it.. 

This commit was SVN r11132.
2006-08-08 16:53:47 +00:00
Jeff Squyres
13dd02a9f4 - Convert MPI_Init(NULL, NULL) to MPI_Init(&argc, &argv) because
apparently some people are using these examples to test other MPI's,
  and some of those MPI's don't handle MPI_Init(NULL, NULL) properly.
  :-)
- Add comments and a print statement to the f90 example to make it
  like the others.

This commit was SVN r11123.
2006-08-08 13:01:17 +00:00
Brian Barrett
59844f2119 Galen noticed that the soh component wasn't linking against the bproc
libraries.  Fix that issue.

This commit was SVN r11119.
2006-08-07 16:20:33 +00:00
Jeff Squyres
c198fd2fd5 Remove some unused variables / compiler warnings.
This commit was SVN r11118.
2006-08-05 10:43:54 +00:00
Jeff Squyres
b6c6d9a2b7 Bring over r10877 and r10881 from the /tmp/tbird branch:
r10877:
add warm up connection option.. of course this only warms up the first
eager btl but this should be adequate for now..

r10881:
Consulted with Galen and did a few things:

- Fix the algorithm to actually make the connections that we want
- Rename the MCA param to mpi_preconnect_all
- Cleanup the code a bit:
  - move the logic to a separate .c file
  - check return codes properly

This commit was SVN r11114.

The following SVN revisions from the original message are invalid or
inconsistent and therefore were not cross-referenced:
  r10877
  r10877
  r10881
  r10881
2006-08-04 14:41:31 +00:00
Brian Barrett
16186978bb - Fix some compile issues in r11109
- indent / whitespace cleanup
- don't set --daemon-debug when pls debug is given, as it seems to make
  the daemons abort.

This commit was SVN r11113.

The following SVN revision numbers were found above:
  r11109 --> open-mpi/ompi@da7df6d257
2006-08-03 18:51:42 +00:00
Brian Barrett
9f28258b3f * squelch stupid compiler warning
This commit was SVN r11111.
2006-08-03 14:42:05 +00:00
Galen Shipman
da7df6d257 monitor bproc node state and terminate the job if a node in our job goes
down.. 

This commit was SVN r11109.
2006-08-03 05:29:49 +00:00
Brian Barrett
65fedbe3be * followup to r10972... Even if MPI_PROC_NULL is given, we should do the
full argument checking (allowing that MPI_PROC_NULL is legal, of course).
  Only after the argument checking do we shortcut.  Fixes trac:237, which
  was caused by moving the MPI_PROC_NULL test in MPI_Bsend_init, 
  but not allowing for MPI_PROC_NULL when checking rank.

This commit was SVN r11108.

The following SVN revision numbers were found above:
  r10972 --> open-mpi/ompi@31c66d92aa

The following Trac tickets were found above:
  Ticket 237 --> https://svn.open-mpi.org/trac/ompi/ticket/237
2006-08-03 04:44:03 +00:00
Jeff Squyres
2371c4fe4d Update svn:ignore for LT 2.0
This commit was SVN r11107.
2006-08-03 02:49:31 +00:00
Brian Barrett
f98d4cd706 * this is now safe to use
This commit was SVN r11105.
2006-08-03 00:20:02 +00:00
Brian Barrett
4176e61049 * Add support for building the F90 bindings library as a shared library
on almost all platforms (except OS X... sigh...).  This is the merge 
  of r10846 - 10894 from the tmp/f90-shared branch to the trunk.

This commit was SVN r11103.

The following SVN revisions from the original message are invalid or
inconsistent and therefore were not cross-referenced:
  r10846
2006-08-03 00:17:31 +00:00
Brian Barrett
0ba0a60ada * Merge in new version of the pt2pt one-sided communication component,
implemented entirely on top of the PML.  This allows us to have a
  one-sided interface even when we are using the CM PML and MTLs for
  point-to-point transport (and therefore not using the BML/BTLs)
* Old pt2pt component was renamed "rdma", as it will soon be having
  real RDMA support added to it.

Work was done in a temporary branch.  Commit is the result of the
merge command:

  svn merge -r10862:11099 https://svn.open-mpi.org/svn/ompi/tmp/bwb-osc-pt2pt

This commit was SVN r11100.

The following SVN revisions from the original message are invalid or
inconsistent and therefore were not cross-referenced:
  r10862
  r11099
2006-08-03 00:10:19 +00:00
Brian Barrett
a21769bbfb * careful with the opal_output when no components are selected
This commit was SVN r11093.
2006-08-02 21:13:33 +00:00
Brian Barrett
bc16f462b9 * print framework and component name during load errors
* return a failure from mtl select code if we don't have a
  component that can run

This commit was SVN r11092.
2006-08-02 20:59:58 +00:00
Brian Barrett
9c30aefff5 * constant is always defined -- use #if, not #ifdef
This commit was SVN r11089.
2006-08-02 18:37:41 +00:00
Ralph Castain
e0cd034e13 Remove unused variable
This commit was SVN r11084.
2006-08-02 12:26:41 +00:00
Brian Barrett
9d5f91997f * updates to build on OS X 10.3
This commit was SVN r11082.
2006-08-01 22:41:51 +00:00
Brian Barrett
a84e557815 Add new loop mode OPAL_EVLOOP_ONELOOP that behaved like OPAL_EVLOOP_ONCE
did pre-libevent update.  The problem is that the behavior of 
OPAL_EVLOOP_ONCE was changed by the OMPI team, which them broke things
during the update, so it had to be reverted to the old meaning of
loop until one event occurs.  OPAL_EVLOOP_ONELOOP will go through the
event loop once (like EVLOOP_NONBLOCK) but will pause in the event
library for a bit (like EVLOOP_ONCE).

fixes trac:234

This commit was SVN r11081.

The following Trac tickets were found above:
  Ticket 234 --> https://svn.open-mpi.org/trac/ompi/ticket/234
2006-08-01 22:23:57 +00:00
Jeff Squyres
7aac77a37c When on the IA64 platform, if we're using the Intel 9.0 v20051201
compiler, automatically disable the ptmalloc component.  It seems that
optimization level -O2 or higher will cause the generated code to do
Bad Things (e.g., opalcc will segv).  Upgrading to the Intel 9.1
compiler seems to fix the problem.

This closes ticket #227.

This commit was SVN r11076.
2006-08-01 18:48:34 +00:00
Ralph Castain
bd7e8febb1 Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.

Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.

IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.

2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.

3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.

This commit was SVN r11075.
2006-08-01 18:42:25 +00:00
Jeff Squyres
7784f1a818 Fix a problem noted by Chris Hennes that MPI_INFO_SET would mistakenly
disallow setting long info values.

This commit was SVN r11074.
2006-08-01 16:07:56 +00:00
Brian Barrett
3b17a9d5ee * Older installations of XCode (even on 10.4) don't have the defines needed
for compiling the x86 stack trace unwinding code.  So don't build it on
  those platforms

This commit was SVN r11073.
2006-08-01 02:06:11 +00:00
Rainer Keller
07ccd84fcf - Get to compile with --enable-progress-thread
This commit was SVN r11069.
2006-07-31 22:40:37 +00:00
Rainer Keller
12166eb0d7 - The intel-based assembler on ia64 (such as NEC's ecc) needs
.proc/.endp-declarations for functions in order to be able to
   link successfully.
   Currently used in configure, only.
   
   There has not been found another arch, where this is necessary.
   So asm-data.txt and base/default.conf has not been changed.

This commit was SVN r11068.
2006-07-31 22:30:07 +00:00
Rainer Keller
bfadfa9eb6 - Get code-coverage to work with gcc-4.x (needs --coverage flag also
when linking)
   This allows ompi-branch optimization. Works now with mpicc wrappers.

This commit was SVN r11067.
2006-07-31 21:55:01 +00:00
Galen Shipman
fb9210463f clarify assignment..
This commit was SVN r11065.
2006-07-31 20:54:54 +00:00
Galen Shipman
ce0b8d9b48 cleanup of cq/srq sizing..
This commit was SVN r11061.
2006-07-31 17:24:39 +00:00
Brian Barrett
1cc3acd6d8 * fix some warnings from the new event code
This commit was SVN r11060.
2006-07-31 17:03:30 +00:00
Jeff Squyres
520147f209 Clean up the Fortran MPI sentinel values per problem reported on the
users mailing list:

  http://www.open-mpi.org/community/lists/users/2006/07/1680.php

Warning: this log message is not for the weak.  Read at your own
risk.

The problem was that we had several variables in Fortran common blocks
of various types, but their C counterparts were all of a type
equivalent to a fortran double complex.  This didn't seem to matter
for the compilers that we tested, but we never tested static builds
(which is where this problem seems to occur, at least with the Intel
compiler: the linker compilains that the variable in the common block
in the user's .o file was of one size/alignment but the one in the C
library was a different size/alignment).

So this patch fixes the sizes/types of the Fortran common block
variables and their corresponding C instantiations to be of the same
sizes/types. 

But wait, there's more.

We recently introduced a fix for the OSX linker where some C versions
of the fortran common block variables (e.g.,
_ompi_fortran_status_ignore) were not being found when linking
ompi_info (!).  Further research shows that the code path for
ompi_info to require ompi_fortran_status_ignore is, unfortunately,
necessary (a quirk of how various components pull in different
portions of the code base -- nothing in ompi_info itself requires
fortran or MPI knowledge, of course).

Hence, the real problem was that there was no code path from ompi_info
to the portion of the code base where the C globals corresponding to
the Fortran common block variables were instantiated.  This is because
the OSX linker does not automatically pull in .o files that only
contain unintialized global variables; the OSX linker typically only
pulls in a .o file from a library if it either has a function that is
used or have a global variable that is initialized (that's the short
version; lots of details and corner cases omitted).  Hence, we changed
the global C variables corresponding to the fortran common blocks to
be initialized, thereby causing the OSX linker to pull them in
automatically -- problem solved.  At the same time, we moved the
constants to another .c file with a function, just for good measure.

However, this didn't really solve the problem:

1. The function in the file with the C versions of the fortran common
   block variables (ompi/mpi/f77/test_constants_f.c) did not have a
   code path that was reachable from ompi_info, so the only reason
   that the constants were found (on OSX) was because they were
   initialized in the global scope (i.e., causing the OSX compiler to
   pull in that .o file).

2. Initializing these variable in the global scope causes problems for
   some linkers where -- once all the size/type problems mentioned
   above were fixed -- the alignments of fortran common blocks and C
   global variables do not match (even though the types of the Fortran
   and C variables match -- wow!).  Hence, initializing the C
   variables would not necessarily match the alignment of what Fortran
   expected, and the linker would issue a warning (i.e., the alignment
   warnings referenced in the original post).

The solution is two-fold:

1. Move the Fortran variables from test_constants_f.c to
   ompi/mpi/runtime/ompi_mpi_init.c where there are other global
   constants that *are* initialized (that had nothing to do with
   fortran, so the alignment issues described above are not a factor),
   and therefore all linkers (including the OSX linker) will pull in
   this .o file and find all the symbols that it needs.

2. Do not initialize the C variables corresponding to the Fortran
   common blocks in the global scope.  Indeed, never initialize them
   at all (because we never need their *values* - we only check for
   their *locations*).  Since nothing is ever written to these
   variables (particularly in the global scope), the linker does not
   see any alignment differences during initialization, but does make
   both the C and Fortran variables have the same addresses (this
   method has been working in LAM/MPI for over a decade).

There were some comments here in the OMPI code base and in the LAM
code base that stated/implied that C variables corresponding to
Fortran common blocks had to have the same alignment as the Fortran
common blocks (i.e., 16).  There were attempts in both code bases to
ensure that this was true.  However, the attempts were wrong (in both
code bases), and I have now read enough Fortran compiler documentation
to convince myself that matching alignments is not required (indeed,
it's beyond our control).  As long as C variables corresponding to
Fortran common blocks are not initialized in the global scope, the
linker will "figure it out" and adjust the alignment to whatever is
required (i.e., the greater of the alignments).  Specifically (to
counter comments that no longer exist in the OMPI code base but still
exist in the LAM code base):

- there is no need to make attempts to specially align C variables
  corresponding to Fortran common blocks
- the types and sizes of C variables corresponding to Fortran common
  blocks should match, but do not need to be on any particular
  alignment 

Finally, as a side effect of this effort, I found a bunch of
inconsistencies with the intent of status/array_of_statuses
parameters.  For all the functions that I modified they should be
"out" (not inout).

This commit was SVN r11057.
2006-07-31 15:07:09 +00:00
Galen Shipman
c9e0eda190 Initialize the completion queue to a reasonable size based on maximum number
of send/receives outstanding.

Use ibv_cq_resize if available after initial creation of completion queue if
cq_size is too small (based on number of peers). 

This commit was SVN r11053.
2006-07-30 00:58:40 +00:00
Jeff Squyres
a181a0ee1e Move dr back up to 1.2
This commit was SVN r11049.
2006-07-28 18:44:47 +00:00