Brian and I chatted about this on the phone today. Conclusions that
we came to:
1. We need to add a few lines of code to ensure that the MCA base
refuses to open components that have a different MCA version number
(i.e., dlopen a DSO, dlsym to get the component struct, check the
version
Ralph,
On our quest for better shared memory collective, we did some runs
with 16 cores Intel machines. The SM worked as expected, as far as I
can tell. Unfortunately we only have one such node, so we never tried
more than 16 processes.
george.
On Jul 24, 2008, at 11:13 PM, Ralph Casta
Yo folks
We are trying to run some tests on a new cluster and are having a
problem telling hardware, system software, and OMPI failures apart.
This is a 16-ppn Opteron system running SLURM under RHEL (forget the
precise version), with IB and OMPI 1.2.6.
Everything launches just fine and s
There is another hidden danger here that has bitten us before -
namely, I challenge someone to remember that they fixed something last
week that (a) really does need to go over to 1.3, (b) hasn't already
done so, and (c) isn't now intertwined with someone else's interim fix
that they don't
Jeff Squyres wrote:
I think that this is exactly the problem -- when a developer puts
something back to the trunk, they (including me!) almost always commit
what they think is the fix to the problem. But hindsight is 20/20.
Case in point: it took Ralph and me and others over a week to fully
I think that this is exactly the problem -- when a developer puts
something back to the trunk, they (including me!) almost always commit
what they think is the fix to the problem. But hindsight is 20/20.
Case in point: it took Ralph and me and others over a week to fully
fix the SM/paffin
On Jul 24, 2008, at 8:44 AM, Ralf Wildenhues wrote:
I have no idea what Jeff's approach is,
My approach was to move some of the f77 files so that we could
traverse directories in order nicely.
and I would not recommend
entering some makefiles more than once, but what you can do is list
so
Terry,
I did not and I will not enforce any policy at this point. I'm
confident developers in this community can take such decisions by
themselves, without restrictions from the RM. As a hint, the most
basic common sense (make sure it compile and it really solve the
problem it is supposed
It might be worthwhile to spell out the conditions of when someone
should let changes soak or not. Considering your changeset 19011 was
putback without much soak time. I am not saying 19011 needed more soak
time just that I think it adds potential confusion as to what one really
needs to do v
* George Bosilca wrote on Thu, Jul 24, 2008 at 02:44:04PM CEST:
> I was hoping we can get some hints/help from Ralf, but unfortunately his
> email address is not CC to the emails and I don't know if he's reading
> the devel mailing list. I'll resend my email with.
I read the list, but reading la
* Brian Barrett wrote on Thu, Jul 24, 2008 at 02:28:45PM CEST:
> When I looked at the same problem in LAM, I couldn't get the
> dependencies right between libraries when only one makefile was used. It
> worked up until I would do a parallel build, then would die because the
> libraries weren't
I was hoping we can get some hints/help from Ralf, but unfortunately
his email address is not CC to the emails and I don't know if he's
reading the devel mailing list. I'll resend my email with.
george.
On Jul 24, 2008, at 2:28 PM, Brian Barrett wrote:
George -
When I looked at the same
George -
When I looked at the same problem in LAM, I couldn't get the
dependencies right between libraries when only one makefile was used.
It worked up until I would do a parallel build, then would die because
the libraries weren't ready at the right time. There's probably a
way, but I
I tend to agree with Brian's comments, I would like to see this pushed
into the 1.3 branch asap. However, I'm concerned with the impact on
the code base of the required modifications as described on the TRAC
ticket and on the email thread.
I wonder if we cannot use the same technique that w
14 matches
Mail list logo
