Hello,
Testing a new BTL component I get SIGSEGV
in mca_pml_ob1_recv_request_progress_frag().
I found that recvreq points to an unmapped
memory location. As far as I understand recvreq
is taken directly from the PML header of the
message received?
To better understand the message flow, could yo
Hi Ralph,
- "Ralph Castain" wrote:
> UmmmI'll let you guys work this out on PLPA. However, just to
> clarify, OMPI currently binds to cores, not logical cpus. It is the
> PLPA that is "dumb" and provides the plumbing to do what OMPI tells
> it.
>
> :-)
Ahh, if that's the case then
Oops! I forgot to attach those 3 pages from the Libtool docs. Here
they are...
On Jul 23, 2009, at 5:53 PM, Jeff Squyres (jsquyres) wrote:
We have talked many times about doing proper versioning for OMPI's .so
libraries (e.g., libmpi.so -- *not* our component DSOs). After
reading up on the
UmmmI'll let you guys work this out on PLPA. However, just to
clarify, OMPI currently binds to cores, not logical cpus. It is the
PLPA that is "dumb" and provides the plumbing to do what OMPI tells it.
:-)
On Jul 24, 2009, at 2:18 AM, Chris Samuel wrote:
- "Jeff Squyres" wrote:
- "Jeff Squyres" wrote:
> PLPA does not currently deal with cpusets.
I think it can get close enough if it assumes that
its initial affinity list is the subset of cores that
it can choose from when setting CPU affinity.
As for whether OMPI or PLPA should choose, I suspect
it's better if OM
Hi Bert,
- "Bert Wesarg" wrote:
> The Cpus_allowed* fields in /proc//status are the same as
> sched_getaffinity returns and the /proc//cpuset needs to be
> resolved, i.e. where is the cpuset fs mounted?
The convention is to mount it on /dev/cpuset.
Unfortunately you cannot mount both the c
- "Jeff Squyres" wrote:
Hi Jeff,
> I'm the "primary PLPA" guy that Ralph referred to, and I was on
> vacation last week -- sorry for missing all the chatter.
No worries!
> Based on your mails, it looks like you're out this week -- so little
> will likely occur. I'm at the MPI Forum st
