On 8/15/13 10:30 AM, "George Bosilca" wrote:
>
>On Aug 15, 2013, at 18:06 , Joshua Ladd wrote:
>
>> Maybe this is a stupid question, but in this case (I believe this goes
>>all the way back to our initial discussion on OSHMEM), how does one fall
>>back onto send/recv semantics when the call is m
>
>
> -Original Message-
> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph Castain
> Sent: Thursday, August 15, 2013 11:55 AM
> To: Open MPI Developers
; From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph Castain
> Sent: Thursday, August 15, 2013 11:55 AM
> To: Open MPI Developers
> Subject: Re: [OMPI devel] [EXTERNAL] OpenSHMEM round 2
>
> I see the problem. Yoda is directly calling bml_get without first checking to
&
devel-boun...@open-mpi.org] On Behalf Of Ralph Castain
Sent: Thursday, August 15, 2013 11:55 AM
To: Open MPI Developers
Subject: Re: [OMPI devel] [EXTERNAL] OpenSHMEM round 2
I see the problem. Yoda is directly calling bml_get without first checking to
see if the bml_btl supports rdma operations. If you
:devel-boun...@open-mpi.org] On Behalf Of Ralph Castain
> Sent: Wednesday, August 14, 2013 6:13 PM
> To: Open MPI Developers
> Subject: Re: [OMPI devel] [EXTERNAL] OpenSHMEM round 2
>
> Here's the backtrace:
>
> (gdb) where
> #0 0x in ?? ()
> #1 0x
-
From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph Castain
Sent: Wednesday, August 14, 2013 6:13 PM
To: Open MPI Developers
Subject: Re: [OMPI devel] [EXTERNAL] OpenSHMEM round 2
Here's the backtrace:
(gdb) where
#0 0x in ?? ()
#1 0x7fac6b8d8921 in m
>> srun -n 2 test_shmem
>>
>> Josh
>>
>>
>> -Original Message-
>> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph Castain
>> Sent: Wednesday, August 14, 2013 5:32 PM
>> To: Open MPI Developers
>> Subject: Re:
ge-
> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph Castain
> Sent: Wednesday, August 14, 2013 5:32 PM
> To: Open MPI Developers
> Subject: Re: [OMPI devel] [EXTERNAL] OpenSHMEM round 2
>
> Can you point me to a test program that would exercise it? I'd
I Developers
Subject: Re: [OMPI devel] [EXTERNAL] OpenSHMEM round 2
Can you point me to a test program that would exercise it? I'd like to give it
a try first.
I'm okay with on by default as it builds its own separate library, and with the
RFC
On Aug 14, 2013, at 2:03 PM, "Bar
test_shmem
Josh
-Original Message-
From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph Castain
Sent: Wednesday, August 14, 2013 5:32 PM
To: Open MPI Developers
Subject: Re: [OMPI devel] [EXTERNAL] OpenSHMEM round 2
Can you point me to a test program that would exercise it? I&#
>>
>> Other than cleaning up warnings and resolving the segfault that Brian
>> observed are we on a good course to getting this upstream? Is it
>> reasonable to file an RFC for three weeks out?
>>
>> Josh
>>
>> -----Original Message-
>&
;observed are we on a good course to getting this upstream? Is it
>reasonable to file an RFC for three weeks out?
>
>Josh
>
>-Original Message-
>From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Barrett,
>Brian W
>Sent: Sunday, August 11, 2013 1:42 PM
>
ilto:devel-boun...@open-mpi.org] On Behalf Of Barrett, Brian W
Sent: Sunday, August 11, 2013 1:42 PM
To: Open MPI Developers
Subject: Re: [OMPI devel] [EXTERNAL] OpenSHMEM round 2
Ralph -
I think those warnings are just because of when they last synced with the
trunk; it looks like they haven&#x
Ralph -
I think those warnings are just because of when they last synced with the
trunk; it looks like they haven't updated in the last week, when those
(and some usnic fixes) went in.
More concerning is the --enable-picky stuff and the disabling of SHMEM in
the right places.
Brian
On 8/11/13 1
Turning off the enable_picky, I get it to compile with the following warnings:
pget_elements_x_f.c:70: warning: no previous prototype for
'ompi_get_elements_x_f'
pstatus_set_elements_x_f.c:70: warning: no previous prototype for
'ompi_status_set_elements_x_f'
ptype_get_extent_x_f.c:69: warning: n
FWIW, I couldn't get it to build - this is on a simple Xeon-based system under
CentOS 6.2:
cc1: warnings being treated as errors
spml_yoda_getreq.c: In function 'mca_spml_yoda_get_completion':
spml_yoda_getreq.c:98: error: pointer targets in passing argument 1 of
'opal_atomic_add_32' differ in s
On 8/6/13 10:30 AM, "Joshua Ladd" wrote:
>Dear OMPI Community,
>
>Please find on Bitbucket the latest round of OSHMEM changes based on
>community feedback. Please git and test at your leisure.
>
>https://bitbucket.org/jladd_math/mlnx-oshmem.git
Josh -
In general, I think everything looks ok.
17 matches
Mail list logo
