Ick. I see the problem; I'll fix.
Thanks!
On Dec 6, 2005, at 1:48 PM, George Bosilca wrote:
I just did something stupid. I tyupe in the wrong windows and I get a
segfault from ompi_info. It's not a big deal, as it's definitively
a user
mistake. But I don't think we should crash either ...
I just did something stupid. I tyupe in the wrong windows and I get a
segfault from ompi_info. It's not a big deal, as it's definitively a user
mistake. But I don't think we should crash either ...
Just try:
ompi_info --mca rds all
george.
"We must accept finite disappointment, but we must ne
Thanks muchly for tracking this down! I'm working on the fixes right
now; will commit shortly.
On Sep 27, 2005, at 11:59 AM, Ferris McCormick wrote:
On Mon, 2005-09-26 at 20:09 +, Ferris McCormick wrote:
On Mon, 2005-09-26 at 14:59 +, Ferris McCormick wrote:
On Fri, 2005-09-16 at
On Mon, 2005-09-26 at 20:09 +, Ferris McCormick wrote:
> On Mon, 2005-09-26 at 14:59 +, Ferris McCormick wrote:
> > On Fri, 2005-09-16 at 11:35 -0500, Brian Barrett wrote:
> > > On Sep 16, 2005, at 8:44 AM, Ferris McCormick wrote:
> > >
> > > > ==
>
On Mon, 2005-09-26 at 14:59 +, Ferris McCormick wrote:
> On Fri, 2005-09-16 at 11:35 -0500, Brian Barrett wrote:
> > On Sep 16, 2005, at 8:44 AM, Ferris McCormick wrote:
> >
> > > ==
> > > fmccor@polylepis util [235]% ./opal_timer
> > > --> frequency: 90
On Fri, 2005-09-16 at 11:35 -0500, Brian Barrett wrote:
> On Sep 16, 2005, at 8:44 AM, Ferris McCormick wrote:
>
> > ==
> > fmccor@polylepis util [235]% ./opal_timer
> > --> frequency: 9
> > --> cycle count
> > Slept approximately 903151189 cycle
On Sep 16, 2005, at 2:17 PM, Ferris McCormick wrote:
On Fri, 2005-09-16 at 12:52 -0500, Brian Barrett wrote:
On Sep 16, 2005, at 11:35 AM, Brian Barrett wrote:
On Sep 16, 2005, at 8:44 AM, Ferris McCormick wrote:
==
fmccor@polylepis util [235]% ./opa
On Fri, 2005-09-16 at 12:52 -0500, Brian Barrett wrote:
> On Sep 16, 2005, at 11:35 AM, Brian Barrett wrote:
>
> > On Sep 16, 2005, at 8:44 AM, Ferris McCormick wrote:
> >
> >> ==
> >> fmccor@polylepis util [235]% ./opal_timer
> >> --> frequency: 9
>
On Sep 16, 2005, at 11:35 AM, Brian Barrett wrote:
On Sep 16, 2005, at 8:44 AM, Ferris McCormick wrote:
==
fmccor@polylepis util [235]% ./opal_timer
--> frequency: 9
--> cycle count
Slept approximately 903151189 cycles, or 1003501 us
--> usec
On Sep 16, 2005, at 8:44 AM, Ferris McCormick wrote:
==
fmccor@polylepis util [235]% ./opal_timer
--> frequency: 9
--> cycle count
Slept approximately 903151189 cycles, or 1003501 us
--> usecs
Slept approximately 18446744073289684648 us
===
On Thu, 2005-09-15 at 20:25 -0500, Brian Barrett wrote:
> On Sep 15, 2005, at 8:17 PM, Ferris McCormick wrote:
>
> > On Thu, 15 Sep 2005, Ferris McCormick wrote:
> >
> >
> > A little experimentation suggests that instead of "mov %tick, ..." we
> > need
> > "rd %tick,%o4". I'll verify tomorrow w
On Sep 15, 2005, at 8:17 PM, Ferris McCormick wrote:
On Thu, 15 Sep 2005, Ferris McCormick wrote:
On Thu, 2005-09-15 at 15:26 -0500, Brian Barrett wrote:
Gah... The #if 0 and missing header are my bad - I'll fix those
tonight. can you rerun the compiler on the file that errors out, but
with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 15 Sep 2005, Ferris McCormick wrote:
On Thu, 2005-09-15 at 15:26 -0500, Brian Barrett wrote:
Gah... The #if 0 and missing header are my bad - I'll fix those
tonight. can you rerun the compiler on the file that errors out, but
with the -S
On Thu, 2005-09-15 at 15:26 -0500, Brian Barrett wrote:
> Gah... The #if 0 and missing header are my bad - I'll fix those
> tonight. can you rerun the compiler on the file that errors out, but
> with the -S option to get the assembly file? It would be useful to
> know what is on lines 61,
Gah... The #if 0 and missing header are my bad - I'll fix those
tonight. can you rerun the compiler on the file that errors out, but
with the -S option to get the assembly file? It would be useful to
know what is on lines 61, 195, and 292.
Thanks!
Brian
On Sep 15, 2005, at 8:36 AM, Fe
> On Wed, 14 Sep 2005, Brian Barrett wrote:
>
> > I committed some code that should fix the timer problems on SPARC
> > linux. Can you either svn up and try again (or, if you are using
> > nightly builds) try tomorrow's tarball and see if it works? The test
> > tests/util/opal_timer.c should gi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 14 Sep 2005, Brian Barrett wrote:
I committed some code that should fix the timer problems on SPARC
linux. Can you either svn up and try again (or, if you are using
nightly builds) try tomorrow's tarball and see if it works? The test
tests
I committed some code that should fix the timer problems on SPARC
linux. Can you either svn up and try again (or, if you are using
nightly builds) try tomorrow's tarball and see if it works? The test
tests/util/opal_timer.c should give an indication as to whether
everything is working ok
Here is a bit more on the sparc/linux SegFault from everything unless
configured with --enable-debug:
On Mon, 2005-09-12 at 13:34 -0500, Brian Barrett wrote:
> Ok, I see what's happening, although I'm not sure the two problems
> are actually related. The first is that the component to provide
On Mon, 2005-09-12 at 13:34 -0500, Brian Barrett wrote:
> Ok, I see what's happening, although I'm not sure the two problems
> are actually related. The first is that the component to provide
> high resolution timer support on Linux is disabling itself because:
>
>1) it doesn't know how t
Ok, I see what's happening, although I'm not sure the two problems
are actually related. The first is that the component to provide
high resolution timer support on Linux is disabling itself because:
1) it doesn't know how to figure out the clock rate of the CPU
2) there's no assembly fo
On Sep 12, 2005, at 2:05 PM, Ferris McCormick wrote:
HOWEVER: If I configure with --enable-debug, two things happen:
1. I have to build ompi/mca/rcache/rb by hand because of incorrect
CFLAGS;
FWIW, the rcache guys are currently off working in a /tmp branch, and
they have fixed this problem
On Mon, 2005-09-12 at 11:14 -0500, Brian Barrett wrote:
> Thanks for the heads up. We are not seeing this on other platforms,
> so it might be a Sparc-specific issue. Any chance you could compile
> with debugging symbols and generate a backtrace? Also, could you
> send the contents of /pro
Thanks for the heads up. We are not seeing this on other platforms,
so it might be a Sparc-specific issue. Any chance you could compile
with debugging symbols and generate a backtrace? Also, could you
send the contents of /proc/cpuinfo (long story...)?
Thanks!
Brian
On Sep 12, 2005, at
Sorry if this is old news, configuration problem, or whatever. I have
been tied up with other things, and have not been able to follow ompi
very closely.
I just built openmpi-1.0a1r7305 for testing, and notice that ompi_info
(and all other ompi tests) give
mca: base: components_open: component li
25 matches
Mail list logo