Hey all,
Sorry for my lag on this thread, I'm still settling back into
Bloomington and catching up on email traffic.
This is certainly my fault WRT the addition of the RDS call to
orte_init_stage1(). I never tested the case where a process is a
singleton and not the seed. :(
Since the R
On Aug 18, 2005, at 5:34 PM, David Daniel wrote:
On Aug 18, 2005, at 4:24 PM, Brian Barrett wrote:
On Aug 18, 2005, at 4:53 PM, David Daniel wrote:
A question for those who did the ROMIO port...
The ROMIO component seems to be based on version 1.2.5.1 (the last
version of ROMIO released ind
On Aug 18, 2005, at 4:24 PM, Brian Barrett wrote:
On Aug 18, 2005, at 4:53 PM, David Daniel wrote:
A question for those who did the ROMIO port...
The ROMIO component seems to be based on version 1.2.5.1 (the last
version of ROMIO released independently). Did anyone make any
progress using t
On Aug 18, 2005, at 4:53 PM, David Daniel wrote:
A question for those who did the ROMIO port...
The ROMIO component seems to be based on version 1.2.5.1 (the last
version of ROMIO released independently). Did anyone make any
progress using the ROMIO from later MPICH's (version 1.2.6 etc.)?
See
A question for those who did the ROMIO port...
The ROMIO component seems to be based on version 1.2.5.1 (the last
version of ROMIO released independently). Did anyone make any
progress using the ROMIO from later MPICH's (version 1.2.6 etc.)?
Seems to me these are fairly broken as far as c
Rainer's problem looks different than the one in orte_init_stage1.
ompi_info reports that he doesn't have any sds components built.
Actually, it doesn't list *any* orte components, which seems broken
to me. I should pretty print an error message and abort if an sds
isn't found, but it lo
I'm seeing a problem in orte_init_stage1 when running w/ a persistent
daemon.
The problem is that the orte_inti call attempts to call rds subsystem
directly,
which is not supposed to be exposed at that level. rds is used internally by
the rmgr - and only initialized on the seed. The proxy rmgr i
FWIW, I do not get these segv's when compiling 64 bit in Opteron...
I can run the IMB's (and other apps) to completion when using tcp,self.
(I did find that I missed the MPI_Allreduce count==0 case, which I
just committed a fix for)
On Aug 18, 2005, at 2:04 PM, Rainer Keller wrote:
Hell
Hello Brian,
sure, attached is output of ompi_info -a on:
model name : AMD Opteron(tm) Processor 246
Linux c3-19 2.4.21-OC_NUMA_fix #4 SMP Tue Nov 30 16:03:38 CET 2004 x86_64
unknown
It's a SuSE SLES8 distribution with the following libc:
hpcraink@c3-19:~ > /lib64/libc.so.6
GNU C Library
Just to double check, can you run ompi_info and send me the results?
Thanks,
Brian
On Aug 18, 2005, at 10:45 AM, Rainer Keller wrote:
Hello,
see the "same" (well probably not exactly same) thing here in
Opteron with
64bit (-g and so on), I get:
#0 0x40085160 in orte_sds_base_con
Yeah, although there really shouldn't be a way for the pointer to be
NULL. Was this a static build? I was seeing some weird memory
issues on static builds last night... I'll take a look on odin and
see what I can find.
Brian
On Aug 18, 2005, at 11:18 AM, Tim S. Woodall wrote:
Brian,
Brian,
Wasn't the introduction of sds part of your changes for redstorm? Any ideas
why it would be NULL here?
Thanks,
Tim
Rainer Keller wrote:
Hello,
see the "same" (well probably not exactly same) thing here in Opteron with
64bit (-g and so on), I get:
#0 0x40085160 in orte_sds_b
Hello,
see the "same" (well probably not exactly same) thing here in Opteron with
64bit (-g and so on), I get:
#0 0x40085160 in orte_sds_base_contact_universe ()
at ../../../../../orte/mca/sds/base/sds_base_interface.c:29
29 return orte_sds_base_module->contact_universe();
(gdb
Sigh, sorry - I take it back again. mpirun segfaults still but my other
test codes don't (ones that exercise the registry). I've compiled OMPI
with -m32 and I've compiled my MPI codes with -m32 as well as my
registry test codes. The mpirun still segfaults:
[bluesteel]~/ompi-test > gdb mpir
Ok Tim -- feel free to make it so...
On Aug 18, 2005, at 9:33 AM, Tim S. Woodall wrote:
Brian Barrett wrote:
On Aug 17, 2005, at 5:08 AM, Jeff Squyres wrote:
Is ob1 and the BTLs stable enough to be made the default?
Is it getting time to retire teg and the PTLs?
I'd vote for maki
I don't know why but make -k didn't work for me. It complain that
some file are missing, it show me the list of files but that's all
(it does not create them). So the quickest way I found around this
problem is to use the output of "make -k" to know which files it look
for and then create t
FYI, this only happens when I let OMPI compile 64bit on Linux. When I
throw in there CFLAGS=FFLAGS=CXXFLAGS=-m32 orted, my myriad of test
codes, mpirun, registry subscription codes, and JNI all work like a champ.
Something's wrong with the 64bit it appears to me.
-- Nathan
Correspondence
-
Did everyone catch Brian's e-mail?
Because of a change I made last night to how the sm ptl builds
(sorry, it was necessary -- there was a corner case that we didn't
handle) and Automake not being "smart enough," you'll need to do the
following after you update to the latest trunk:
cd
Brian Barrett wrote:
On Aug 17, 2005, at 5:08 AM, Jeff Squyres wrote:
Is ob1 and the BTLs stable enough to be made the default?
Is it getting time to retire teg and the PTLs?
I'd vote for making ob1 the default. I'd like to leave teg and the
ptls for a bit longer, if only because
Hi all -
Just to let you know that last night I committed some more changes to
opal_progress(), along with a bunch of code to access cycle counters
or high resolution, low overhead timers on a bunch of platforms.
opal_progress() now makes the decision of whether to tick the event
library
On Aug 18, 2005, at 8:04 AM, Gleb Natapov wrote:
On Thu, Aug 18, 2005 at 07:08:07AM -0500, Brian Barrett wrote:
Sorry about that - some files moved around yesterday afternoon. You
can either re-run autogen.sh / configure / make again and that
*should* fix the problem, or you can:
It doesn't
On Thu, Aug 18, 2005 at 07:08:07AM -0500, Brian Barrett wrote:
> Sorry about that - some files moved around yesterday afternoon. You
> can either re-run autogen.sh / configure / make again and that
> *should* fix the problem, or you can:
It doesn't :(
>
> cd ompi/mca/ptl/sm
> rm .dep
Hello,
On Thursday 18 August 2005 12:47, Jeff Squyres wrote:
> What platforms / compilers are we going to officially test / support
> for the 1.0 release? Help me fill in this list...
> Linux 32 bit -- 2.4 and 2.6
> gcc 3.x
> intel (what version(s))?
> pathscale (what version(s))?
>
Sorry about that - some files moved around yesterday afternoon. You
can either re-run autogen.sh / configure / make again and that
*should* fix the problem, or you can:
cd ompi/mca/ptl/sm
rm .deps/*
make -k
cd ../../../
Brian
On Aug 18, 2005, at 7:02 AM, Gleb Natapov wrote:
I can't compile today's svn code:
gcc -shared .libs/ptl_self.o .libs/ptl_self_component.o -pthread -lm
-lutil -Wl,-soname -Wl,mca_ptl_self.so -o .libs/mca_ptl_self.so
creating mca_ptl_self.la
(cd .libs && rm -f mca_ptl_self.la && ln -s ../mca_ptl_self.la
mca_ptl_self.la)
make[4]: Leaving direct
As of late morning yesterday, the CS department LDAP woes appear to
have been made much better (I hesitate to say "totally fixed" -- time
will tell). I didn't want to send this out yesterday because I wanted
to see how well things were working yesterday afternoon.
But things are going reasona
What platforms / compilers are we going to officially test / support
for the 1.0 release? Help me fill in this list...
Linux 32 bit -- 2.4 and 2.6
gcc 3.x
intel (what version(s))?
pathscale (what version(s))?
pgi (what version(s))?
Linux 64 bit -- 2.4 and 2.6
gcc 3.x
int
Hi,
Thanks for the info about IMB. I will download the latest one.
Pallas was running fine in intra-node case. But it is hanging in
inter-node case.
I have a small MPI program which send/recv a char. I have tested this
program across the nodes (inter-node) as follows. It ran fine across the
nod
28 matches
Mail list logo
