Re: [OMPI users] orte-clean hang in 1.8.5

[Ralph Castain]

Not expected, no - but given how little it is used any more, I’m not surprised. 
I can take a quick gander and see if I can easily fix it.


> On Jun 8, 2015, at 3:10 PM, David Shrader  wrote:
> 
> Hello All,
> 
> I had a user report that orte-clean is hanging on him with Open MPI 1.8.5. 
> Here are the steps I used to reproduce what he reported:
> 
> %> which orte-clean
> /usr/projects/hpcsoft/toss2/moonlight/openmpi/1.6.5-gcc-4.4/bin/orte-clean
> %> mpirun -n 1 
> /usr/projects/hpcsoft/toss2/moonlight/openmpi/1.6.5-gcc-4.4/bin/orte-clean
> Reported: 1 (out of 1) daemons - 1 (out of 1) procs
> [hangs]
> 
> I have found that the same behavior does not happen using 1.6.5. That is, I 
> get a command prompt after running orte-clean.
> 
> Is this behavior expected? I am not familiar with orte-clean, so I am not 
> sure if it hanging when used in this fashion is an actual problem with 
> orte-clean. If it is unexpected behavior, I'll dig some more.
> 
> Thank you very much for your time,
> David
> 
> -- 
> David Shrader
> HPC-3 High Performance Computer Systems
> Los Alamos National Lab
> Email: dshrader  lanl.gov
> 
> ___
> users mailing list
> us...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
> Link to this post: 
> http://www.open-mpi.org/community/lists/users/2015/06/27052.php

[OMPI users] orte-clean hang in 1.8.5

[David Shrader]

Hello All,

I had a user report that orte-clean is hanging on him with Open MPI 
1.8.5. Here are the steps I used to reproduce what he reported:


%> which orte-clean
/usr/projects/hpcsoft/toss2/moonlight/openmpi/1.6.5-gcc-4.4/bin/orte-clean
%> mpirun -n 1 
/usr/projects/hpcsoft/toss2/moonlight/openmpi/1.6.5-gcc-4.4/bin/orte-clean

Reported: 1 (out of 1) daemons - 1 (out of 1) procs
[hangs]

I have found that the same behavior does not happen using 1.6.5. That 
is, I get a command prompt after running orte-clean.


Is this behavior expected? I am not familiar with orte-clean, so I am 
not sure if it hanging when used in this fashion is an actual problem 
with orte-clean. If it is unexpected behavior, I'll dig some more.


Thank you very much for your time,
David

--
David Shrader
HPC-3 High Performance Computer Systems
Los Alamos National Lab
Email: dshrader  lanl.gov

Re: [OMPI users] Bug: Disabled mpi_leave_pinned for GPUDirect and InfiniBand during run-time caused by GCC optimizations

[Jeff Squyres (jsquyres)]

On Jun 8, 2015, at 11:27 AM, Dave Goodell (dgoodell)  wrote:
> 
> My suggestion is to try to create a small reproducer program that we can send 
> to the GCC folks with the claim that we believe it to be a buggy 
> optimization.  Then we can see whether they agree and if not, how they defend 
> that behavior.
> 
> We probably still need a workaround for now though, and the "volatile" 
> approach seems fine to me.

+1

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI users] Building OpenMPI on Raspberry Pi 2

[Jeff Layton]

Jeff,

Sorry - I was traveling for a week and didn't have to the RPi.


What happens if you don't supply CCASFLAGS at all?



The output from "make" is below. It died when it tried to compile
atomic-local. It says the processor doesn't support ARM mode "dmb".

Thanks!

Jeff



pi@raspberrypi /work/pi/src/openmpi-1.8.5 $ make
Making all in config
make[1]: Entering directory '/work/pi/src/openmpi-1.8.5/config'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/work/pi/src/openmpi-1.8.5/config'
Making all in contrib
make[1]: Entering directory '/work/pi/src/openmpi-1.8.5/contrib'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/work/pi/src/openmpi-1.8.5/contrib'
Making all in opal
make[1]: Entering directory '/work/pi/src/openmpi-1.8.5/opal'
Making all in include
make[2]: Entering directory '/work/pi/src/openmpi-1.8.5/opal/include'
make  all-am
make[3]: Entering directory '/work/pi/src/openmpi-1.8.5/opal/include'
make[3]: Leaving directory '/work/pi/src/openmpi-1.8.5/opal/include'
make[2]: Leaving directory '/work/pi/src/openmpi-1.8.5/opal/include'
Making all in asm
make[2]: Entering directory '/work/pi/src/openmpi-1.8.5/opal/asm'
  CC   asm.lo
rm -f atomic-asm.S
ln -s "../../opal/asm/generated/atomic-local.s" atomic-asm.S
  CPPASatomic-asm.lo
atomic-asm.S: Assembler messages:
atomic-asm.S:7: Error: selected processor does not support ARM mode `dmb'
atomic-asm.S:15: Error: selected processor does not support ARM mode `dmb'
atomic-asm.S:23: Error: selected processor does not support ARM mode `dmb'
atomic-asm.S:55: Error: selected processor does not support ARM mode `dmb'
atomic-asm.S:70: Error: selected processor does not support ARM mode `dmb'
atomic-asm.S:86: Error: selected processor does not support ARM mode 
`ldrexd r4,r5,[r0]'
atomic-asm.S:91: Error: selected processor does not support ARM mode 
`strexd r1,r6,r7,[r0]'
atomic-asm.S:107: Error: selected processor does not support ARM mode 
`ldrexd r4,r5,[r0]'
atomic-asm.S:112: Error: selected processor does not support ARM mode 
`strexd r1,r6,r7,[r0]'

atomic-asm.S:115: Error: selected processor does not support ARM mode `dmb'
atomic-asm.S:130: Error: selected processor does not support ARM mode 
`ldrexd r4,r5,[r0]'

atomic-asm.S:135: Error: selected processor does not support ARM mode `dmb'
atomic-asm.S:136: Error: selected processor does not support ARM mode 
`strexd r1,r6,r7,[r0]'

Makefile:1608: recipe for target 'atomic-asm.lo' failed
make[2]: *** [atomic-asm.lo] Error 1
make[2]: Leaving directory '/work/pi/src/openmpi-1.8.5/opal/asm'
Makefile:2149: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/work/pi/src/openmpi-1.8.5/opal'
Makefile:1698: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

Re: [OMPI users] Bug: Disabled mpi_leave_pinned for GPUDirect and InfiniBand during run-time caused by GCC optimizations

[Dave Goodell (dgoodell)]

On Jun 5, 2015, at 8:47 PM, Gilles Gouaillardet  
wrote:

> i did not use the term "pure" properly.
> 
> please read instead "posix_memalign is a function that does not modify any 
> user variable"
> that assumption is correct when there is no wrapper, and incorrect in our 
> case.

My suggestion is to try to create a small reproducer program that we can send 
to the GCC folks with the claim that we believe it to be a buggy optimization.  
Then we can see whether they agree and if not, how they defend that behavior.

We probably still need a workaround for now though, and the "volatile" approach 
seems fine to me.

-Dave

Re: [OMPI users] CygWin compilation of OpenMPI-1.8.5

[Marco Atzeri]

On 6/7/2015 5:52 PM, Ilias Miroslav wrote:

Greetings,

CygWin is interesting intermediating environment between Windows and Linux-like 
architectures, and the OpenMPI project is good platform for enabling parallel 
calculations.

Here is my OpenMPI building experience with some problems encountered (with 
up-to-date CygWin & OpenMPI):


cygwin already provides openmpi 1.8.5 package.



1) the "default" OpenMPI configuration (no special flags) gives these linking 
errors:


the packages are built with

--disable-mca-dso \
--disable-sysv-shmem \
--enable-cxx-exceptions \
--with-threads=posix \
--without-cs-fs \
--with-mpi-param_check=always \
--enable-contrib-no-build=vt,libompitrace \

--enable-mca-no-build=paffinity,installdirs-windows,timer-windows,shmem-sysv



2) The OpenMPI configuration with the flags specified by
https://www.open-mpi.org/community/lists/users/2014/04/24166.php
produces working mpif90,mpicc,mpicxx... executables.

However, the "make check" testing  gives the second test wrong (see below).


the only current failure is on x86_64
   assertion "opal_atomic_cmpset

all the other tests pass.


Any help how to fix this test issue ?


use cygwin packages
;-)


Miro


Regards
Marco

[OMPI users] CygWin compilation of OpenMPI-1.8.5

[Ilias Miroslav]

Greetings,

CygWin is interesting intermediating environment between Windows and Linux-like 
architectures, and the OpenMPI project is good platform for enabling parallel 
calculations.

Here is my OpenMPI building experience with some problems encountered (with 
up-to-date CygWin & OpenMPI):

1) the "default" OpenMPI configuration (no special flags) gives these linking 
errors:

make[2]: Leaving directory 
'/home/milias/bin/openmpi_1.8.5_gnu/openmpi-1.8.5/opal'
Making all in mca/compress/gzip
make[2]: Entering directory 
'/home/milias/bin/openmpi_1.8.5_gnu/openmpi-1.8.5/opal/mca/compress/gzip'
  CCLD mca_compress_gzip.la
.libs/compress_gzip_component.o:compress_gzip_component.c:(.text+0x5b): 
undefined reference to `opal_output_ver bose'
.libs/compress_gzip_component.o:compress_gzip_component.c:(.text+0x5b): 
relocation truncated to fit: R_X86_64_P C32 against undefined symbol 
`opal_output_verbose'
.libs/compress_gzip_component.o:compress_gzip_component.c:(.text+0x79): 
undefined reference to `opal_output_ver bose'
.libs/compress_gzip_component.o:compress_gzip_component.c:(.text+0x79): 
relocation truncated to fit: R_X86_64_P C32 against undefined symbol 
`opal_output_verbose'
.
.
.

2) The OpenMPI configuration with the flags specified by  
https://www.open-mpi.org/community/lists/users/2014/04/24166.php 
produces working mpif90,mpicc,mpicxx... executables. 

However, the "make check" testing  gives the second test wrong (see below).

Any help how to fix this test issue ?

Miro
.
.
.
=
ompi_predefined_op_t = 2048 bytes
ompi_op_t = 1344 bytes
super = 0, 16
o_name = 16, 64
o_flags = 84, 4 ***
o_f_to_c_index = 88, 4
o_func = 96, 624 ***
o_3buff_instrinsic = 720, 624
=
ompi_predefined_datatype_t = 512 bytes
ompi_datatype_t = 464 bytes
=
ompi_predefined_win_t = 512 bytes
ompi_win_t = 168 bytes
w_base = 0, 16
w_lock = 16, 32
w_name = 48, 64
w_group = 112, 8
w_flags = 120, 2
w_keyhash = 128, 8 ***
w_f_to_c_index = 136, 4
error_handler = 144, 8 ***
errhandler_type = 152, 4
w_osc_module = 160, 8 ***
=
ompi_predefined_info_t = 256 bytes
ompi_info_t = 88 bytes
super = 0, 64
i_f_to_c_index = 64, 4
i_lock = 72, 8 ***
i_freed = 80, 1
=
ompi_predefined_file_t = 1536 bytes
ompi_file_t = 768 bytes
super = 0, 16
f_comm = 16, 8
f_filename = 24, 8
f_amode = 32, 4
f_info = 40, 8 ***
f_flags = 48, 4
f_f_to_c_index = 52, 4
error_handler = 56, 8
errhandler_type = 64, 4
f_io_version = 68, 4
f_io_selected_component = 72, 296
f_io_selected_module = 368, 392
f_io_selected_data = 760, 8
PASS: predefined_gap_test.exe
Running in CWD: /home/milias/bin/openmpi_1.8.5_gnu/openmpi-1.8.5/o
mpi/debuggers
Trying to open file with private namespace: ./libompi_dbg_msgq
Failed to open with private namespace: File not found
Retrying with global namespace
File failed to open with global namespace: File not found
Failed to open with private namespace: File not found
Retrying with global namespace
File failed to open with global namespace: File not found
FAIL: dlopen_test.exe

1 of 2 tests failed
Please report to http://www.open-mpi.org/community/help/

Makefile:1865: recipe for target 'check-TESTS' failed
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory '/home/milias/bin/openmpi_1.8.5_gnu/ope
nmpi-1.8.5/ompi/debuggers'
Makefile:1988: recipe for target 'check-am' failed
make[2]: *** [check-am] Error 2
make[2]: Leaving directory '/home/milias/bin/openmpi_1.8.5_gnu/ope
nmpi-1.8.5/ompi/debuggers'
Makefile:3138: recipe for target 'check-recursive' failed
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory '/home/milias/bin/openmpi_1.8.5_gnu/ope
nmpi-1.8.5/ompi'
Makefile:1698: recipe for target 'check-recursive' failed
make: *** [check-recursive] Error 1
UMB+milias@chemia:~/bin/openmpi_1.8.5_gnu/openmpi-1.8.5/.