tems, a modification to /etc/sysctl.d/10-ptrace.conf is
> required.
>
> Change:
> kernel.yama.ptrace_scope = 1
>
> to
>
> kernel.yama.ptrace_scope = 0
>
> and restart your system so the change can take effect.
>
> Thanks,
>
> Sam
> ____
Hi Sam,
On Thu, 18 Oct 2012 15:08:59 +
"Gutierrez, Samuel K" wrote:
>
> I really appreciate your pointing me in the right direction. It turns
> out that on this particular system had /etc/sysctl.d/10-ptrace.conf
> was set to 1. Changing this to 0 fixed the problem. I'm not sure if
> this is
> On Thu, 2 Aug 2012 10:25:53 -0400
> Jeff Squyres wrote:
>
> > On Aug 1, 2012, at 9:44 AM, Christopher Yeoh wrote:
> >
> (gdb) bt
> #0 0x008039720d6c in .pthread_cond_wait ()
> from /lib64/power6/libpthread.so.0 #1 0x041299d8 in
> opal_c
Hi Paul,
On Fri, 03 Aug 2012 13:43:22 +0200
Paul Kapinos wrote:
> Christopher,
> I cannot reproduce your problem on my fresh installed 1.6.1rc2. I've
> used the attached program which is essentially your test case with a
> bit modification sin order to make in compilable.
The 1.6 tree works fin
On Thu, 2 Aug 2012 10:25:53 -0400
Jeff Squyres wrote:
> On Aug 1, 2012, at 9:44 AM, Christopher Yeoh wrote:
>
> I run one of my MTT configs with --enable-mpi-thread-multiple, but
> only run single-threaded apps (i.e., MPI_THREAD_SINGLE). This just
> checks the bozo case.
>
&
Hi,
I was wondering if anyone else recently had tried to run trunk
configured with --enable-mpi-thread-multiple and an MPI program that
passed MPI_THREAD_MULTIPLE to MPI_Init_thread on a machine using the
openib btl?
I'm seeing even very basic programs hang. If it is working for you,
what archit
rantee that only one thread at a
time will ever call the btl self functions which manipulate those lists.
Regards,
Chris
> george.
>
> On Feb 8, 2012, at 17:57 , Christopher Yeoh wrote:
>
> > Hi,
> >
> > I've noticed that the self btl does not do any lo
Hi,
I've noticed that the self btl does not do any locking. It has one
lock defined but its not actually used anywhere.
So I'm just wondering if that is an oversight or if there is a reason
that we know for sure that there will never be concurrent access
to that particular btl with threads enable
Hi Chris,
On Fri, 13 Jan 2012 09:54:20 +1100
Christopher Samuel wrote:
>
> On 12/01/12 20:34, Christopher Yeoh wrote:
>
> > Cross Memory Attach (CMA) is a pair of new syscalls
> > (process_vm_readv and process_vm_writev) which allow for fast
> > intranode communi
Hi Brad,
WHAT: Adds Cross Memory Attach support to the sm btl
WHY: For faster intranode communication
WHERE: ompi/mca/btl/sm/
WHEN: Open MPI trunk
TIMEOUT: 13/2/2012
Cross Memory Attach (CMA) is a pair of new syscalls (process_vm_readv
and process_vm_writev) which allow for fast intranode
co
On Tue, 13 Dec 2011 20:27:00 -0500
Jeff Squyres wrote:
> On Dec 13, 2011, at 7:59 PM, Christopher Yeoh wrote:
>
> > Sorry, late to the discussion. This is a spurious warning caused by
> > passing the NULL pointer to the opal free function which is
> > actually ok. It w
Hi Mike,
On Mon, 12 Dec 2011 19:46:08 +0200
Mike Dubman wrote:
> Hi guys,
>
> The latest v1.5 from trunk, compiled in debug mode yields following
> error with openib.
> The quick blame leads to the following commit:
>
> r25616 | bosilca | 2011-12-10 00:18:16 +0200 (Sat, 10 Dec 2011) | 4
> line
On 20 Jul 2010 13:03:57 +0100
"N.M. Maclaren" wrote:
>
> Not on most systems. While this is more clearly illegal, similar
> remarks apply to its safety. If there were any debugging C compilers
> around, it might well get trapped, but those are about as common as
> unicorns.
>
> It's a horrible
Hi Jeff,
I've committed a fix for this in r23441
Regards,
Chris
On Mon, 19 Jul 2010 11:58:31 -0400
Jeff Squyres wrote:
> Chris Yeoh --
>
> SVN blame says that this is your line of code. Can you fix?
>
>
> On Jul 17, 2010, at 12:27 PM, Ralph Castain wrote:
>
> > Yo IB-folks
> >
> > Are w
Hi Jeff,
Sorry I've been on vacation so didn't reply sooner - some
comments below...
On Tue, 27 Apr 2010 16:50:49 -0400
Jeff Squyres wrote:
> -
> #if OPAL_ENABLE_DEBUG
> do {
> ftr->seq = ep->eager_rdma_remote.seq;
> } while (!OPAL_ATOMIC_CMPSET_32(&ep->eager_rdma_r
n anyone
see any problems with this change?
Regards,
Chris
On Mon, 2 Nov 2009 21:20:17 -0500
Jeff Squyres wrote:
> Ewww yikes. This could definitely be an issue if we weren't
> (multi-thread) careful when writing these portions of the code. :-(
>
>
> On Oct 28, 2
Hi Jeff,
On Mon, 2 Nov 2009 21:15:15 -0500
Jeff Squyres wrote:
>
> I had to go re-read that whole section on generalized requests; I
> agree with your analysis. Could you open a ticket and submit a
> patch? You might want to look at the back ends to MPI_TEST[_ANY]
> and MPI_WAIT_ANY as wel
Hi Mondrian,
On Mon, 02 Nov 2009 13:22:11 +0100
Mondrian Nuessle wrote:
>
> If I turn on mpi_leave_pinned (and thus the registration cache is
> actually used), I see occasional memory corruption issues for example
> when I call MPI_Allreduce often.
>
> Debugging with valgrind did not lead to an
Hi,
I've been investigating some OpenMPI deadlocks triggered by a test suite
written to test the thread safety of MPI libraries. I'm using OpenMPI 1.3.3.
One of the deadlocks I'm seeing looks like this (the sleep for frame 1 is
something I
inserted when a deadlock is detected so I can attach a d
Hi,
I've been running some threaded test suites against OpenMPI and was
just wanting to clarify something in the specification and how OpenMPI
implements it.
One page 360 of the 2.1 spec there is (in reference to
mpi_grequest_start query function):
Advice to users. query_fn must not set the
20 matches
Mail list logo
