I build on Debian 4.0 and run on Suse 10 and Fedore Core 6. The only
thing I had to enforce is the availability of the corresponding libc
library (the one I build with) on the target OS. Moreover, as my nodes
have different processors, I have to enforce strict x86 code.
george.
On May 22
On May 23, 2008, at 9:56 AM, Josh Hursey wrote:
Unfortunately, as Jeff pointed out, the behavior of frameworks and
components in determining component selection is not consistent in the
codebase. The mca_base_select() commit made things much better, but
there are still frameworks that do not (o
> Either that or udev in not configured properly.
Debian has a correct udev configuration, modulo
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449081
> ib_core/mthca/mlx4 should be loaded automatically by hotplug if HW is
> present. No need for any additional configuration.
Yes (although
> OFED is one distribution of the OpenFabrics software. It can be
> bundled up and packaged differently, too. I suspect that Debian does
> not include OFED directly, because OFED is pretty heavily dependent
> upon RPM. So the OpenFabrics kernel bits must be there somewhere
> (libibv
Unfortunately, as Jeff pointed out, the behavior of frameworks and
components in determining component selection is not consistent in the
codebase. The mca_base_select() commit made things much better, but
there are still frameworks that do not (or cannot) use it, and there
are some behavio
I think that technically, the component can do whatever it wants
(e.g., look at its priority, see 0, and decide to return NULL).
However, to be consistent, we should decide on a specific behavior and
make it uniform to all components.
I'd opt for the ^foo notation to disable a component.
On Fri, May 23, 2008 at 07:19:01AM -0400, Jeff Squyres wrote:
> Brian and I were chatting the other day about random OMPI stuff and
> the topic of the memory hooks came up again. Brian was wondering if
> we should [finally] revisit this topic -- there's a few things that
> could be done to m
Jeff Squyres wrote:
Brian and I were chatting the other day about random OMPI stuff and
the topic of the memory hooks came up again. Brian was wondering if
we should [finally] revisit this topic -- there's a few things that
could be done to make life "better". Two things jump to mind:
-
This mostly makes sense. But let me probe a little more. Can a
component return NULL if it looks at its priority and the priority is
less than or equal to 0? For example, currently the hierarch component
returns NULL when its priority is equal or less than 0. This means that
as a user whe
Yeah (Sorry I didn't reply earlier).
Each component is asked for at least two items of information:
priority (int), and module (struct *).
The priority can range from [INT_MIN | INT_MAX] with the highest
priority selected, even if that priority is negative.
If the component does not want
Brian and I were chatting the other day about random OMPI stuff and
the topic of the memory hooks came up again. Brian was wondering if
we should [finally] revisit this topic -- there's a few things that
could be done to make life "better". Two things jump to mind:
- using mallopt on Linu
We may not have this uniform throughout the code base -- this is one
of the things we wanted to talk about in the Bay area meeting. I
believe that the allowable range for priorities should be [0, 100],
and that if you don't want to be selected, you should return NULL (or
use some other mec
FWIW, I always build for the version of Linux that I'm currently
running.
On May 22, 2008, at 5:33 PM, Don Kerr wrote:
Can anyone set my expectations with their real world experiences
regarding building Open MPI on one release of Linux and running on
another.
If I were to...
Build OMPI o
On Fri, May 23, 2008 at 09:56:44AM +0300, Gleb Natapov wrote:
> On Thu, May 22, 2008 at 08:30:52PM +, Dirk Eddelbuettel wrote:
> > > > Also, if this test depends on the Debian kernel packages, then we're
> > > > back to square one as some folks (like myself) run binary kernels,
> > > > other ma
On Thu, May 22, 2008 at 08:30:52PM +, Dirk Eddelbuettel wrote:
> > > Also, if this test depends on the Debian kernel packages, then we're
> > > back to square one as some folks (like myself) run binary kernels,
> > > other may just hand-compile and this test may not work as we may miss
> > > th
On Thu, May 22, 2008 at 04:19:05PM -0400, Jeff Squyres wrote:
> On May 22, 2008, at 4:07 PM, Dirk Eddelbuettel wrote:
>
> > Is there a test I could run for you?
>
> Can you see if /dev/infiniband exists? If it does, the OpenFabrics
> kernel drivers are running. If not, they aren't.
Either tha
16 matches
Mail list logo
