On Aug 19, 2005, at 8:15 AM, Tim S. Woodall wrote:
Josh,
I believe that although the prior code called ras routines,
they were simple library routines in ras base, that didn't
require ras to be initialized (they just accessed the registry).
Yeah. That's right.
So, w/ the new code, both ra
Josh,
I believe that although the prior code called ras routines,
they were simple library routines in ras base, that didn't
require ras to be initialized (they just accessed the registry).
So, w/ the new code, both ras/rds components must be initialized/selected.
My opinion would be to add the
Hello Brian
On Thursday 18 August 2005 23:19, Brian Barrett wrote:
> Rainer's problem looks different than the one in orte_init_stage1.
> ompi_info reports that he doesn't have any sds components built.
You're right, also Your patch is right, as far as I can tell -- had a similar
check, but wasn't
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
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
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
-
Nathan,
I'll try to reproduce this sometime this week - but I'm pretty swamped.
Is Greg also seeing the same behavior?
Thanks,
Tim
Nathan DeBardeleben wrote:
To expand on this further, orte_init() seg faults on both bluesteel
(32bit linux) and sparkplug (64bit linux) equally. The required
c
To expand on this further, orte_init() seg faults on both bluesteel
(32bit linux) and sparkplug (64bit linux) equally. The required
condition is that orted must be running first (which of course we
require for our work - a persistent orte daemon and registry).
[bluesteel]~/ptp > ./dump_info
Just to clarify:
1: no orted started (meaning the MPIrun or registry programs will
start one by themselves) causes those programs to lock up.
2: starting orted by hand (trying to get these programs to connect to
a centralized one) causes the connecting programs to seg fault.
-- Nathan
Corres
So I dropped an .ompi_ignore into that directory, reconfigured, and
compile worked (yay!).
However, not a lot of progress: mpirun locks up, all my registry test
programs lock up as well. If I start the orted by hand, then any of my
registry calling programs cause segfault:
[sparkplug]~/ptp >
Is this what Tim Prins was working on?
On Aug 16, 2005, at 5:21 PM, Tim S. Woodall wrote:
I'm not sure why this is even building... Is someone working on this?
I thought we had .ompi_ignore files in this directory.
Tim
Nathan DeBardeleben wrote:
So I'm seeing all these nice emails about pe
I'm not sure why this is even building... Is someone working on this?
I thought we had .ompi_ignore files in this directory.
Tim
Nathan DeBardeleben wrote:
So I'm seeing all these nice emails about people developing on OMPI
today yet I can't get it to compile. Am I out here in limbo on this o
So I'm seeing all these nice emails about people developing on OMPI
today yet I can't get it to compile. Am I out here in limbo on this or
are others in the same boat? The errors I'm seeing are about some bproc
code calling undefined functions and they are linked again below.
-- Nathan
Corre
Back from training and trying to test this but now OMPI doesn't compile
at all:
gcc -DHAVE_CONFIG_H -I. -I. -I../../../../include
-I../../../../include -I../../../.. -I../../../..
-I../../../../include -I../../../../opal -I../../../../orte
-I../../../../ompi -g -Wall -Wundef -Wno-long-long -
This is now fixed in SVN. You should no longer need the
--build=i586... hack to compile 32 bit code on Opterons.
Brian
On Aug 12, 2005, at 3:17 PM, Brian Barrett wrote:
On Aug 12, 2005, at 3:13 PM, Nathan DeBardeleben wrote:
We've got a 64bit Linux (SUSE) box here. For a variety of reaso
Actually, Brian just pointed out the problem -- you also need to set
CXXFLAGS=-m32.
On Aug 12, 2005, at 5:15 PM, Jeff Squyres wrote:
That's a neat one. mpicc shouldn't care about any of this stuff --
it's a trivial C++ program that invokes none of the MCA framework
stuff, etc.
I'll try to r
That's a neat one. mpicc shouldn't care about any of this stuff --
it's a trivial C++ program that invokes none of the MCA framework
stuff, etc.
I'll try to replicate.
Just out of curiosity -- do other C++ applications work nicely in 32
bit on that machine? (particularly ones that use std::
OK, so I reconfigured, made, etc:
137 14:29 ./configure CFLAGS=-m32 FFLAGS=-m32
--build=i586-suse-linux --enable-static --disable-shared
--without-threads --prefix=/home/ndebard/local/ompi
--with-devel-headers --disable-io-romio --disable-f77
138 14:48 make clean all install
But
On Aug 12, 2005, at 3:22 PM, Nathan DeBardeleben wrote:
Thanks, trying that now. While I'd like those things in the long run,
they're not needed right now to test what I'm trying to test. Will
let
you know how it goes! (What's the problem, by the way?)
The problem is that I key off the t
Thanks, trying that now. While I'd like those things in the long run,
they're not needed right now to test what I'm trying to test. Will let
you know how it goes! (What's the problem, by the way?)
-- Nathan
Correspondence
-
On Aug 12, 2005, at 3:13 PM, Nathan DeBardeleben wrote:
We've got a 64bit Linux (SUSE) box here. For a variety of reasons
(Java, JNI, linking in with OMPI libraries, etc which I won't get
into)
I need to compile OMPI 32 bit (or get 64bit versions of a lot of other
libraries).
I get various c
29 matches
Mail list logo
