Thanks George. I've started a new trunk tarball creation.
It should finish before MTT runs start tonight. I hope.
On Dec 6, 2007 9:29 PM, George Bosilca wrote:
> Fixed by r16884.
>
>george.
>
>
> On Dec 7, 2007, at 12:46 PM, MPI Team wrote:
>
> >
> > ERROR: Command returned a non-zero exist
Argh, sorry about that... the website changes were checked into svn... but the
main website wasn't svn up'ed... Open MPI v1.2.5rc1 is now there. Enjoy.
On Dec 6, 2007 5:49 PM, Jeff Squyres wrote:
> Tim --
>
> I don't see 1.2.5rc1 posted there...?
>
>
>
> On Dec 6, 2007, at 4:43 PM, Tim Mattox
Fixed by r16884.
george.
On Dec 7, 2007, at 12:46 PM, MPI Team wrote:
ERROR: Command returned a non-zero exist status
make -j 4 distcheck
Start time: Thu Dec 6 21:00:25 EST 2007
End time: Thu Dec 6 21:16:34 EST 2007
=
=
Tim --
I don't see 1.2.5rc1 posted there...?
On Dec 6, 2007, at 4:43 PM, Tim Mattox wrote:
Hi All,
The first release candidate of Open MPI v1.2.5 is now up:
http://www.open-mpi.org/software/ompi/v1.2/
Please run it through it's paces as best you can.
--
Tim Mattox, Ph.D. - http://homepage.m
Hi All,
The first release candidate of Open MPI v1.2.5 is now up:
http://www.open-mpi.org/software/ompi/v1.2/
Please run it through it's paces as best you can.
--
Tim Mattox, Ph.D. - http://homepage.mac.com/tmattox/
tmat...@gmail.com || timat...@open-mpi.org
I'm a bright... http://www.the-
On Thu, Dec 06, 2007 at 09:46:45AM -0500, Tim Prins wrote:
> Also, when we are using threads, there is a case where we do not
> decrement the signaled count, in condition.h:84. Gleb put this in in
> r9451, however the change does not make sense to me. I think that the
> signal count should alway
Done: r16872.
On Dec 6, 2007, at 1:34 PM, Terry Dontje wrote:
Jeff Squyres wrote:
I should also note the following:
- LAM/MPI does the same thing (increments refcount when GROUP_EMPTY
is
returned to the user, and allows GROUP_EMPTY in GROUP_FREE)
- MPICH2 has the following comment in GRO
Jeff Squyres wrote:
I should also note the following:
- LAM/MPI does the same thing (increments refcount when GROUP_EMPTY is
returned to the user, and allows GROUP_EMPTY in GROUP_FREE)
- MPICH2 has the following comment in GROUP_FREE (and code to match):
/* Cannot free the pred
On Thu, 6 Dec 2007, Tim Prins wrote:
Tim Prins wrote:
First, in opal_condition_wait (condition.h:97) we do not release the
passed mutex if opal_using_threads() is not set. Is there a reason for
this? I ask since this violates the way condition variables are supposed
to work, and it seems like t
Jeff Squyres wrote:
I should also note the following:
- LAM/MPI does the same thing (increments refcount when GROUP_EMPTY is
returned to the user, and allows GROUP_EMPTY in GROUP_FREE)
- MPICH2 has the following comment in GROUP_FREE (and code to match):
/* Cannot free the prede
well, the best I could find is the following in section 5.2.1
"MPI_GROUP_EMPTY, which is a valid handle to an empty group, should not
be confused with MPI_GROUP_NULL, which in turn is an invalid handle. The
former may be used as an argument to group operations; the latter, which
is returned wh
I should also note the following:
- LAM/MPI does the same thing (increments refcount when GROUP_EMPTY is
returned to the user, and allows GROUP_EMPTY in GROUP_FREE)
- MPICH2 has the following comment in GROUP_FREE (and code to match):
/* Cannot free the predefined groups, but allo
So the changes that we debated and had Edgar put in *do* break some
intel tests. Doh! :-(
MPI_Group_compare_f
MPI_Group_intersection2_c
MPI_Group_intersection2_f
It looks like these tests are specifically calling MPI_GROUP_FREE on
MPI_GROUP_EMPTY.
I note that there is code in th
On 12/6/07 8:06 AM, "Shipman, Galen M." wrote:
>>>
>>> Do we really need a complete node map? A far as I can tell, it looks
>>> like the MPI layer only needs a list of local processes. So maybe it
>>> would be better to forget about the node ids at the mpi layer and just
>>> return the local
On 12/6/07 8:09 AM, "Shipman, Galen M." wrote:
> Sorry, to be clear that should have been:
>
>> One option is for the RTE to just pass in an enviro variable with a
>> comma-separated list of your local ranks, but that creates a problem down
>> the road when trying to integrate tighter with sy
Sorry, to be clear that should have been:
> One option is for the RTE to just pass in an enviro variable with a
> comma-separated list of your local ranks, but that creates a problem down
> the road when trying to integrate tighter with systems like SLURM where the
> procs would get mass-launched
Tim Prins wrote:
Hi,
A couple of questions.
First, in opal_condition_wait (condition.h:97) we do not release the
passed mutex if opal_using_threads() is not set. Is there a reason for
this? I ask since this violates the way condition variables are supposed
to work, and it seems like there ar
>>
>> Do we really need a complete node map? A far as I can tell, it looks
>> like the MPI layer only needs a list of local processes. So maybe it
>> would be better to forget about the node ids at the mpi layer and just
>> return the local procs.
>
> I agree, though I don't think we want a paral
On Dec 5, 2007, at 11:23 AM, Ralph H Castain wrote:
Well, I think it is pretty obvious that I am a fan of a attribute
system :)
For completeness, I will point out that we also exchange architecture
and hostname info in the modex.
True - except we should note that hostname info is only excha
Hi,
A couple of questions.
First, in opal_condition_wait (condition.h:97) we do not release the
passed mutex if opal_using_threads() is not set. Is there a reason for
this? I ask since this violates the way condition variables are supposed
to work, and it seems like there are situations where
Arlin Davis wrote:
I'm running OFED 1.2.5 and using Chelsio.
From the linux rdma verbs perspective, ibv_create_cq() will create a
cq that is >= the requested depth. The fact that mthca always bumps
the size up to the next power of 2 isn't something udapl can rely on.
It doesn't.
uDAPL pa
:-)
Nice catch. Please commit the fix.
Pasha.
Jeff Squyres wrote:
Hah! Sweet; good catch -- feel free to delete that extra call.
On Dec 5, 2007, at 6:42 PM, Jon Mason wrote:
There is a double call to ompi_btl_openib_connect_base_open in
mca_btl_openib_mca_setup_qps(). It looks like som
On Dec 2, 2007, at 5:11 PM, Richard Graham wrote:
One question – there is a mention a new pml that is essentially CM
+matching.
Why is this no just another instance of CM ?
I'm not sure I understand your question -- the new proposed PML would
be different than CM: it would have matching and
Hah! Sweet; good catch -- feel free to delete that extra call.
On Dec 5, 2007, at 6:42 PM, Jon Mason wrote:
There is a double call to ompi_btl_openib_connect_base_open in
mca_btl_openib_mca_setup_qps(). It looks like someone just forgot to
clean-up the previous call when they added the check
On Dec 5, 2007, at 1:42 PM, Karol Mroz wrote:
Removal of .ompi_ignore should not create build problems for anyone
who
is running without some form of SCTP support. To test this claim, we
built Open MPI with .ompi_ignore removed and no SCTP support on
both an
ubuntu linux and an OSX machine.
25 matches
Mail list logo
