Hmmm...well, my bad. There does indeed appear to be something funny going on
with Leopard. No idea what - it used to work fine. I haven't tested it in
awhile though - I've been test building regularly on Leopard, but running on
Tiger (I misspoke earlier).
For now, I'm afraid you can't run on
Ah -- I didn't notice this before -- do you have a configure script
committed to SVN? If so, this could be the problem.
Whether what Tim sees happens or not will depend on the timestamps
that SVN puts on configure and all of the files dependent upon
configure (Makefile.in, Makefile,
Hi Tim,
that seems wrong for me, too. I could not reproduce this on my computer.
The VT-integration comes with an own configure script, which will not
created by the OMPI's autogen.sh.
I have not really an idea what's going wrong... I suppose, the problem
is that you use another version
of the
So the ompi-checkpoint command connects with the Global Coordinator in
the SnapC 'full' component. The Global Coordinator lives in the HNP
(mpirun/orterun) as determined by the 'full' component. As a result to
start a checkpoint ompi-checkpoint must connect to the HNP.
From a user
Ok so the script is done. It took a bit longer than I had expected,
but when it finished then things sped back up ('24 hours' of data in 6
sec). There are a few more maintenance operations I want to run which
will help out a bit more, but I'll push those to this weekend.
Thanks for your
Hi all (and Josh),
Why the ompi-checkpoint have to contact the HNP specifically? If I use
another process to start the snapshot coordinator, apparently it´s
works fine, no?
PS: I prefer to send this message to the list... to keep it on the
history for further use...
--
Leonardo Fialho
Computer
On Wed, Jan 30, 2008 at 06:48:54PM +0100, Adrian Knoth wrote:
> > What is the real issue behind this whole discussion?
> Hanging connections.
> I'll have a look at it tomorrow.
To everybody who's interested in BTL-TCP, especially George and (to a
minor degree) rhc:
I've integrated something
On Thu, Jan 31, 2008 at 08:45:54AM -0500, Don Kerr wrote:
> This was brought to my attention once before but I don't see this
> message so I just plain forgot about it. :-(
> uDAPL defines its pointers as uint64, "typedef DAT_UINT64 DAT_VADDR",
> and pval is a "void *" which is why the message
This was brought to my attention once before but I don't see this
message so I just plain forgot about it. :-(
uDAPL defines its pointers as uint64, "typedef DAT_UINT64 DAT_VADDR",
and pval is a "void *" which is why the message comes up. If I remove
the cast I believe I get a different
Hi Matthias,
I just noticed something else that seems odd. On a fresh checkout, I did
a autogen and configure. Then I type 'make clean'. Things seem to
progress normally, but once it gets to ompi/contrib/vt/vt/extlib/otf, a
new configure script gets run.
Specifically:
[tprins@sif test]$
Hi,
I am seeing some warnings on the trunk when compiling udapl in 32 bit
mode with OFED 1.2.5.1:
btl_udapl.c: In function 'udapl_reg_mr':
btl_udapl.c:95: warning: cast from pointer to integer of different size
btl_udapl.c: In function 'mca_btl_udapl_alloc':
btl_udapl.c:852: warning: cast
I tried using a fresh trunk, same problem have occured. Here is the
complete configure line. I am using libtool 1.5.22 from fink.
Otherwise everything is standard OS 10.5.
$ ../trunk/configure --prefix=/Users/bouteill/ompi/build --enable-
mpirun-prefix-by-default --disable-io-romio
12 matches
Mail list logo
