Hi,
I've just made a clean checkout of the trunk and built it - I didn't see any
problems. Also the latest MTT test-builds look good.
Could you please re-checkout the trunk to have a clean working copy and try it
again?
Matthias
On Tuesday 22 November 2011 04:15:25 Ralph Castain wrote:
> Hi V
The error you are seeing is usually indicative of some code operating on
memory that isn't aligned properly for a SPARC instruction being used.
The address that is causing the failure is odd aligned which is more
than likely the culprit. If you have a core dump and can disassemble
the code th
On 11/22/2011 5:49 AM, TERRY DONTJE wrote:
The error you are seeing is usually indicative of some code operating
on memory that isn't aligned properly for a SPARC instruction being
used. The address that is causing the failure is odd aligned which is
more than likely the culprit. If you hav
That is very strange. That sym link does not exist in the 1.4.4 tarball -- it
is generated during "make".
You didn't accidentally vpath build using the OMPI v1.2 source, did you? The
rules in the opal/asm/Makefile.am refer to the top_srcdir, which should
implicitly point to the top directory
FWIW, me too -- it builds ok for me, too.
I have a dim recollection of some change a while ago that caused this badness
(i.e., the trunk is fixed, but an old/stale sym link from before the fix makes
it look like the problem is still there).
IIRC, if you rm -rf the ompi/contrib/vt tree and the
Tom / Larry --
Thanks for looking into this.
1. I just replied on https://svn.open-mpi.org/trac/ompi/ticket/2913 about the
sed issue; let's iterate there to find the Right solution.
2. Larry: I'll look at the other issues in your patch more closely after the
Thanksgiving break (I'm supposedly
Ah, yes - I recall that as well now. Thx!
On Nov 22, 2011, at 5:56 AM, Jeff Squyres wrote:
> FWIW, me too -- it builds ok for me, too.
>
> I have a dim recollection of some change a while ago that caused this badness
> (i.e., the trunk is fixed, but an old/stale sym link from before the fix
>
Here's what Nathan and I discussed / decided:
1. Nathan shied away from the name "xpmem" in case some other shared memory
scheme basically did the same thing as XPMEM (i.e., single copy techniques).
(just FYI: xpmem's setup is a little different from KNEM, though, so they
didn't merge in KNEM
So with the aliasing scheme the code for openib would still under
ompi/mca/btl/openib but you could access it with -mca btl ofrc? Ok, so
when an error happens in the openib btl how does it identify itself?
Does it use openib or ofrc? This seems like there could be some user
confusion by adop
1. Personally, I would love to rename the openib BTL to something that makes
sense and is a current name. By "rename", I include "rename the directory" --
so it would be ompi/mca/btl/ofrc, or something like that.
2. Good point about error reporting. I would think that the component (e.g.,
ofr
-10!
george.
On Nov 22, 2011, at 08:38 , Jeff Squyres wrote:
> 1. Personally, I would love to rename the openib BTL to something that makes
> sense and is a current name. By "rename", I include "rename the directory"
> -- so it would be ompi/mca/btl/ofrc, or something like that.
>
> 2. Goo
Roland Dreier wrote:
>
> On Mon, Nov 21, 2011 at 5:51 PM, Lukas Razik wrote:
>> [cluster1:64027] Signal code: Invalid address alignment (1)
>> [cluster1:64027] Failing at address: 0xaa9053
>> [cluster1:64027] [ 0]
> /usr/mpi/gcc/openmpi-1.4.3/lib64/openmpi/mca_pml_ob1.so(+0x62f0)
> [0xf801020
TERRY DONTJE wrote:
>On 11/22/2011 5:49 AM, TERRY DONTJE wrote:
>The error you are seeing is usually indicative of some code operating on
>memory that isn't aligned properly for a SPARC instruction being used. The
>address that is causing the failure is odd aligned which is more than likely
>t
Roland Dreier wrote:
> On Tue, Nov 22, 2011 at 3:05 PM, Lukas Razik wrote:
>> #0 0xf8010229ba9c in mca_pml_ob1_send_request_start_copy
> (sendreq=0xb23200, bml_btl=0xb29050, size=0) at pml_ob1_sendreq.c:551
>> 551 hdr->hdr_match.hdr_ctx =
> sendreq->req_send.req_base.req_comm->c
14 matches
Mail list logo