Generally, the user defaults to the soft limit and can use ulimit to
set values up to the hard limit. Tim's suggestion bumps the soft
limit up to the hard limit, so all the user could do with ulimit is
move the per-user limit back down.
brian
On Dec 6, 2005, at 3:35 PM, Jeff Squyres wrote
With Tim's response to this -- I'm curious (so that we get correct
information on the FAQ) -- is the /etc/security/limit.conf method a
system-wide way of setting these values, and "ulimit -l" a per-user
way of setting it?
That doesn't sound quite right to me -- I'm assuming that a user
ca
Hi Daryl,
Sounds like this might be a ulimit issue, what do you get when you
run ulimit -l?
Also, check out: http://www.open-mpi.org/faq/?category=infiniband
Thanks,
Galen
On Dec 6, 2005, at 10:46 AM, Daryl W. Grunau wrote:
Hi, I'm running OMPI 1.1a1r8378 on 2.6.14 + recent OpenIB stack a
Daryl,
Try this:
Original Message
Subject: RE: only root running mpi jobs with 1.0.1rc5
List-Post: users@lists.open-mpi.org
Date: Thu, 01 Dec 2005 18:49:46 -0700
From: Joshua Aune
Reply-To: lu...@lnxi.com
Organization: Linux Networx
To: Todd Wilde
CC: Matthew Finlay , twood.
Is this on a BProc cluster?
If so, Tim Woodall pointed this out to me last week and alas, I
haven't committed the fix yet. It's not your fault, it's a mistake
on our part; but it's a harmless -- albeit annoying -- warning (this
is only on the trunk, not in the release branch).
On Dec 6,
Hi, I'm running OMPI 1.1a1r8378 and get the following warnings every time I
run. I'm not setting any such value at runtime:
--
WARNING: A user-supplied value attempted to override the read-only MCA
parameter named "p
Hi, I'm running OMPI 1.1a1r8378 on 2.6.14 + recent OpenIB stack and getting
the following runtime error:
[0,1,0][btl_openib.c:803:mca_btl_openib_module_init] error creating high
priority cq for mthca0 errno says Cannot allocate memory
[0,1,3][btl_openib.c:803:mca_btl_openib_module_init] error cre
On Dec 5, 2005, at 4:05 PM, Pierre Valiron wrote:
I tried to experiment open-mpi on our Solaris10 v40z cluster hoping
it might surpass lam/mpi 7.1.2b28...
I used the following script to compile in 64 bit mode:
The configure runs fine and the make aborts very rapidly.
I attach the log for
George Bosilca wrote:
Pierre,
The problem seems to come from the fact that we do not detect how to
generate the assembly code for our atomic operations. As a result we fall
back on the gcc mode for 32 bits architectures.
Here is the corresponding output from the configure script:
checking if
Pierre,
The problem seems to come from the fact that we do not detect how to
generate the assembly code for our atomic operations. As a result we fall
back on the gcc mode for 32 bits architectures.
Here is the corresponding output from the configure script:
checking if cc supports GCC inline as
10 matches
Mail list logo
