On 8/6/07 5:55 PM, "Jeff Squyres" wrote:
> On Aug 6, 2007, at 2:33 PM, Ralph H Castain wrote:
>
>>> This is probably my fault somehow;
>>
>> Isn't everything?? :-)
>
> I believe that there is an official OMPI rule about this, yes. ;-)
>
>>> I can look into this but not
>>> immediately. I'
On Aug 6, 2007, at 2:42 PM, Lisandro Dalcin wrote:
having to call XXX.Free() for every
object i get from a call like XXX.Get_something() is really an
unnecesary pain.
Gotcha.
But I don't see why this means that you need to know if an MPI handle
points to an intrinsic object or not...?
Beca
On Aug 6, 2007, at 2:33 PM, Ralph H Castain wrote:
This is probably my fault somehow;
Isn't everything?? :-)
I believe that there is an official OMPI rule about this, yes. ;-)
I can look into this but not
immediately. I'm guessing this is related to the IOF fix that I put
in last week s
On Aug 6, 2007, at 8:08 AM, Bill Wichser wrote:
Now I have another issue, which we fixed, with ROMIO/PVFS2/and openmpi
1.2.3. It seems that ROMIO support is way behind in openmpi and
what we
did was basically copy the stuff from mpich2, apply the pvfs2 romio
patch and our problems went away.
I forgot to mention: Brian and I chatted today and we have both been
building the 1.2 branch with AM 1.10 / AC 2.61 for a long time and
it's been fine.
So we're throwing it on the to-do list to upgrade the nightly tarball
generation process to AM 1.10 / AC 2.61.
As for upgrading the Libto
On Aug 6, 2007, at 2:48 PM, Ralf Wildenhues wrote:
This fixes the problem for us (we stole it from a libtool mailing
list post from a long time ago). If this could be applied to the
Libtool development trunk, that would be great... :-)
The patch has two issues. First a simple one, it should
On Aug 6, 2007, at 3:05 PM, dispan...@sobel.ls.la wrote:
* Brian Barrett [06.08.2007 18:09]:
On Aug 5, 2007, at 3:05 PM, dispan...@sobel.ls.la wrote:
Can you try the attached patch? It's pretty close to what you've
suggested, but should eliminate one corner case that you could, in
theory, ru
* Brian Barrett [06.08.2007 18:09]:
> On Aug 5, 2007, at 3:05 PM, dispan...@sobel.ls.la wrote:
>
> Can you try the attached patch? It's pretty close to what you've
> suggested, but should eliminate one corner case that you could, in
> theory, run into with your solution. You are using a nig
Hello Jeff,
* Jeff Squyres wrote on Mon, Aug 06, 2007 at 04:27:59PM CEST:
> On Aug 5, 2007, at 3:41 PM, Ralf Wildenhues wrote:
>
> >> WHY: https://svn.open-mpi.org/trac/ompi/ticket/982 is fixed by newer
> >> Libtool snapshots (e.g., 1.2444 2007/04/10 is what I have installed
> >> at Cisco).
[...]
On 8/1/07, Jeff Squyres wrote:
> On Jul 31, 2007, at 6:43 PM, Lisandro Dalcin wrote:
>> having to call XXX.Free() for every
> > object i get from a call like XXX.Get_something() is really an
> > unnecesary pain.
>
> Gotcha.
>
> But I don't see why this means that you need to know if an MPI handle
On 8/6/07 1:51 PM, "Jeff Squyres" wrote:
> On Aug 6, 2007, at 11:49 AM, Ralph H Castain wrote:
>
>> 1. if everything is being done on localhost, I do not see any of
>> the IO from
>> the child process. Mpirun executes and completes cleanly, however.
>> Because,
>> the spawn'd child terminates
On Aug 6, 2007, at 11:49 AM, Ralph H Castain wrote:
1. if everything is being done on localhost, I do not see any of
the IO from
the child process. Mpirun executes and completes cleanly, however.
Because,
the spawn'd child terminates so quickly, I haven't been able to
positively
confirm it
Yo all
I've been playing with the trunk today and found it appears to be broken for
comm_spawn. I'm getting two types of errors, perhaps related:
1. if everything is being done on localhost, I do not see any of the IO from
the child process. Mpirun executes and completes cleanly, however. Because
On Aug 5, 2007, at 3:05 PM, dispan...@sobel.ls.la wrote:
I fixed the problem by setting the peer_state to
MCA_OOB_TCP_CONNECTING
after creating the socket, which works for me. I'm not sure if
this is
always correct, though.
Can you try the attached patch? It's pretty close to what you've
On Aug 5, 2007, at 3:41 PM, Ralf Wildenhues wrote:
WHAT: Upgrade to a newer Libtool 2.1 nightly snapshot (we are
currently using 1.2362 2007/01/23) for making OMPI tarballs.
WHY: https://svn.open-mpi.org/trac/ompi/ticket/982 is fixed by newer
Libtool snapshots (e.g., 1.2444 2007/04/10 is what I
Thanks Jeff! I looked and didn't find anything but sure enough, there
it is!
Now I have another issue, which we fixed, with ROMIO/PVFS2/and openmpi
1.2.3. It seems that ROMIO support is way behind in openmpi and what we
did was basically copy the stuff from mpich2, apply the pvfs2 romio
pat
On Mon, Aug 06, 2007 at 09:53:20AM -0400, Bill Wichser wrote:
> We have run across an issue, probably more related to openib than to
> openmpi but don't know how to resolve.
>
> Linux kernel - 2.6.9-55.0.2.ELsmp x86_64
fork (and thus system()) is not supported by openib in this kernel.
To get sys
Bill --
Check out http://www.open-mpi.org/faq/?category=openfabrics#ofa-fork.
To my knowledge, RHEL4 has not yet received a hotfix that will allow
fork() with OpenFabrics verbs applications when memory is still
registered in the parent.
On Aug 6, 2007, at 7:53 AM, Bill Wichser wrote:
We
Dear all,
while hunting for memory leaks I found the google performance tools quite
useful. The included memory manager has the feature for checking for memory
leak. Unlike other tools you can use this feature without any recompilation
and still get some nice call graph locating the memory allo
We have run across an issue, probably more related to openib than to
openmpi but don't know how to resolve.
Linux kernel - 2.6.9-55.0.2.ELsmp x86_64
libibverbs-1.0.4-7
openmpi - it doesn't matter - 1.1.5 and 1.2.3 both fail.
When the sample code is run across IB nodes, using the IB interface,
20 matches
Mail list logo
