February 2014 - discuss - mailman3.cels.anl.gov

MPICH 3.1rc3 packages for Ubuntu, Debian and Slackware (x86 and amd64)
by Marcelo Soares Souza 07 Feb '14

07 Feb '14

mpich-3.1rc3 packages * Ubuntu 13.10/14.04 - amd64 http://www.cebacad.net/files/mpich/ubuntu/mpich-3.1rc3/mpich_3.1rc3-1ubuntu… - x86 http://www.cebacad.net/files/mpich/ubuntu/mpich-3.1rc3/mpich_3.1rc3-1ubuntu… * Debian 7.3.0 (Wheezy) - amd64 http://www.cebacad.net/files/mpich/debian/mpich-3.1rc3/mpich_3.1rc3-1debian… - x86 http://www.cebacad.net/files/mpich/debian/mpich-3.1rc3/mpich_3.1rc3-1debian… * Slackware 14.1 - amd64 http://www.cebacad.net/files/mpich/slackware/mpich-3.1rc3/mpich-3.1rc3-x86_… - x86 http://www.cebacad.net/files/mpich/slackware/mpich-3.1rc3/mpich-3.1rc3-i486… Enjoy! -- Marcelo Soares Souza https://marcelo.juntadados.org Diaspora* https://diaspora.juntadados.org/u/marcelo Friendica http://friendica.ambientedigital.org/profile/marcelo

1 0

Re: [mpich-discuss] Parallel test hanging with mpich on rhel7
by Balaji, Pavan 06 Feb '14

06 Feb '14

Thanks. That’s very useful analysis. Would you be willing to try the attached patch to see if it solves this issue? — Pavan On 2/6/14, 6:04 PM, "Orion Poplawski" <orion(a)cora.nwra.com> wrote: >On 02/06/2014 09:12 AM, Kenneth Raffenetti wrote: >> Hi Orion, >> >> On 02/04/2014 03:23 PM, Orion Poplawski wrote: >>> However, I'm still seeing a hang on our Fedora builders in a different >>>test: >>> >>> >>> make[4]: Entering directory >>>`/builddir/build/BUILD/hdf5-1.8.12/mpich/testpar' >>> ============================ >>> Testing t_mpi >>> >>> Full log: >>> >>>http://koji.fedoraproject.org/koji/getfile?taskID=6492001&name=build.log >>> >>> Unfortunately I'm not able to reproduce this on my own machines so I'm >>>at a >>> loss here. >> >> We'll look into this and let you know if we find anything in our >>testing. >> >> Ken > >I may have something - one special thing about the Fedora builders is that >they do not have network access. And in the particular environment that >is >failing, ssh is outputting: > >ssh: Could not resolve hostname buildvm-11.phx2.fedoraproject.org: Name or >service not known > >this output seems to wedge mpiexec. Here is some strace snippets: > > strace -f mpirun -np 4 ./xCbtest_MPI-LINUX-0 >execve("/usr/lib64/mpich/bin/mpirun", ["mpirun", "-np", "4", >"./xCbtest_MPI-LINUX-0"], [/* 46 vars */]) = 0 >.... > >[pid 7662] execve("/usr/bin/ssh", ["/usr/bin/ssh", "-x", >"buildvm-11.phx2.fedoraproject.or"..., >"\"/usr/lib64/mpich/bin/hydra_pmi_"..., >"--control-port", "buildvm-11.phx2.fedoraproject.or"..., "--rmk", "user", >"--launcher", "ssh", "--demux", "poll", "--pgid", "0", "--retries", "10", >...], [/* 46 vars */]) = 0 > >[pid 7662] write(2, "ssh: Could not resolve hostname "..., 94) = 94 >[pid 7661] <... poll resumed> ) = 1 ([{fd=10, revents=POLLIN}]) >[pid 7662] exit_group(255) = ? >[pid 7661] fcntl(10, F_GETFL) = 0 (flags O_RDONLY) >[pid 7661] fcntl(10, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 >[pid 7661] fcntl(2, F_GETFL) = 0x1 (flags O_WRONLY) >[pid 7661] fcntl(2, F_SETFL, O_WRONLY|O_NONBLOCK) = 0 >[pid 7661] read(10, "ssh: Could not resolve hostname "..., 65536) = 94 >[pid 7661] write(2, "ssh: Could not resolve hostname "..., 94ssh: Could >not >resolve hostname buildvm-11.phx2.fedoraproject.org: Name or service not >known >) = 94 >[pid 7661] gettimeofday({1391730785, 32416}, NULL) = 0 >[pid 7661] poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=8, >events=POLLIN}, {fd=10, events=POLLIN}], 4, 4294967295 <unfinished ...> >[pid 7662] ﯯ exited with 255 ﯯ ><... poll resumed> ) = 2 ([{fd=8, revents=POLLHUP}, >{fd=10, >revents=POLLHUP}]) >--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7662, >si_status=255, >si_utime=0, si_stime=0} --- >brk(0) = 0x1e0b000 >brk(0x1e3a000) = 0x1e3a000 >fcntl(8, F_GETFL) = 0 (flags O_RDONLY) >fcntl(8, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 >fcntl(1, F_GETFL) = 0x1 (flags O_WRONLY) >fcntl(1, F_SETFL, O_WRONLY|O_NONBLOCK) = 0 >read(8, "", 65536) = 0 >close(8) = 0 >read(10, "", 65536) = 0 >close(10) = 0 >gettimeofday({1391730785, 33070}, NULL) = 0 > >and we are stuck here.... > > >Full logs for a bit are here: >http://kojipkgs.fedoraproject.org//work/tasks/2917/6502917/build.log > > >Is there some way we can disable mpiexec trying to use ssh? > > >-- >Orion Poplawski >Technical Manager 303-415-9701 x222 >NWRA, Boulder/CoRA Office FAX: 303-415-9702 >3380 Mitchell Lane orion(a)nwra.com >Boulder, CO 80301 http://www.nwra.com >_______________________________________________ >discuss mailing list discuss(a)mpich.org >To manage subscription options or unsubscribe: >https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Parallel test hanging with mpich on rhel7
by Orion Poplawski 06 Feb '14

06 Feb '14

On 02/06/2014 05:04 PM, Orion Poplawski wrote: > Is there some way we can disable mpiexec trying to use ssh? I'm working around it for now with "-host localhost". -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

1 0

Re: [mpich-discuss] Parallel test hanging with mpich on rhel7
by Orion Poplawski 06 Feb '14

06 Feb '14

On 02/06/2014 09:12 AM, Kenneth Raffenetti wrote: > Hi Orion, > > On 02/04/2014 03:23 PM, Orion Poplawski wrote: >> However, I'm still seeing a hang on our Fedora builders in a different test: >> >> >> make[4]: Entering directory `/builddir/build/BUILD/hdf5-1.8.12/mpich/testpar' >> ============================ >> Testing t_mpi >> >> Full log: >> http://koji.fedoraproject.org/koji/getfile?taskID=6492001&name=build.log >> >> Unfortunately I'm not able to reproduce this on my own machines so I'm at a >> loss here. > > We'll look into this and let you know if we find anything in our testing. > > Ken I may have something - one special thing about the Fedora builders is that they do not have network access. And in the particular environment that is failing, ssh is outputting: ssh: Could not resolve hostname buildvm-11.phx2.fedoraproject.org: Name or service not known this output seems to wedge mpiexec. Here is some strace snippets: + strace -f mpirun -np 4 ./xCbtest_MPI-LINUX-0 execve("/usr/lib64/mpich/bin/mpirun", ["mpirun", "-np", "4", "./xCbtest_MPI-LINUX-0"], [/* 46 vars */]) = 0 .... [pid 7662] execve("/usr/bin/ssh", ["/usr/bin/ssh", "-x", "buildvm-11.phx2.fedoraproject.or"..., "\"/usr/lib64/mpich/bin/hydra_pmi_"..., "--control-port", "buildvm-11.phx2.fedoraproject.or"..., "--rmk", "user", "--launcher", "ssh", "--demux", "poll", "--pgid", "0", "--retries", "10", ...], [/* 46 vars */]) = 0 [pid 7662] write(2, "ssh: Could not resolve hostname "..., 94) = 94 [pid 7661] <... poll resumed> ) = 1 ([{fd=10, revents=POLLIN}]) [pid 7662] exit_group(255) = ? [pid 7661] fcntl(10, F_GETFL) = 0 (flags O_RDONLY) [pid 7661] fcntl(10, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 [pid 7661] fcntl(2, F_GETFL) = 0x1 (flags O_WRONLY) [pid 7661] fcntl(2, F_SETFL, O_WRONLY|O_NONBLOCK) = 0 [pid 7661] read(10, "ssh: Could not resolve hostname "..., 65536) = 94 [pid 7661] write(2, "ssh: Could not resolve hostname "..., 94ssh: Could not resolve hostname buildvm-11.phx2.fedoraproject.org: Name or service not known ) = 94 [pid 7661] gettimeofday({1391730785, 32416}, NULL) = 0 [pid 7661] poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}], 4, 4294967295 <unfinished ...> [pid 7662] +++ exited with 255 +++ <... poll resumed> ) = 2 ([{fd=8, revents=POLLHUP}, {fd=10, revents=POLLHUP}]) --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7662, si_status=255, si_utime=0, si_stime=0} --- brk(0) = 0x1e0b000 brk(0x1e3a000) = 0x1e3a000 fcntl(8, F_GETFL) = 0 (flags O_RDONLY) fcntl(8, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 fcntl(1, F_GETFL) = 0x1 (flags O_WRONLY) fcntl(1, F_SETFL, O_WRONLY|O_NONBLOCK) = 0 read(8, "", 65536) = 0 close(8) = 0 read(10, "", 65536) = 0 close(10) = 0 gettimeofday({1391730785, 33070}, NULL) = 0 and we are stuck here.... Full logs for a bit are here: http://kojipkgs.fedoraproject.org//work/tasks/2917/6502917/build.log Is there some way we can disable mpiexec trying to use ssh? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

1 0

Re: [mpich-discuss] Parallel test hanging with mpich on rhel7
by Kenneth Raffenetti 06 Feb '14

06 Feb '14

Hi Orion, On 02/04/2014 03:23 PM, Orion Poplawski wrote: > However, I'm still seeing a hang on our Fedora builders in a different test: > > > make[4]: Entering directory `/builddir/build/BUILD/hdf5-1.8.12/mpich/testpar' > ============================ > Testing t_mpi > > Full log: > http://koji.fedoraproject.org/koji/getfile?taskID=6492001&name=build.log > > Unfortunately I'm not able to reproduce this on my own machines so I'm at a > loss here. We'll look into this and let you know if we find anything in our testing. Ken

1 0

Re: [mpich-discuss] Option '-iface' broken when MPICH is configured with '--enable-strict'
by Balaji, Pavan 06 Feb '14

06 Feb '14

Whoops, hit send to quickly. I’ve created a ticket for it. Here it is: https://trac.mpich.org/projects/mpich/ticket/2013 I’m a bit surprised that Hydra/mpiexec is able to detect “eth0”, while mpich is not able to resolve it. We might be doing something weird there to make sure our check is consistent on both sides. Either way, if Hydra doesn’t have the right headers to resolve interfaces, it should be able to disable that option. Thanks for pointing this out. — Pavan On 2/4/14, 3:52 PM, "Jan Bierbaum" <jan.bierbaum(a)tudos.org> wrote: >Hi! > >Although I'm not sure whether this should be considered a bug or just an >annoyance, I thought it would be a good idea to bring it up here because >it took me quiet some time to figure out the underlying problem. > >For those not interested in the details: My suggestion is to disable >'-iface' completely when MPICH is configured with '--enable-strict'. >When the option is used in such a situation, some descriptive error >message should be displayed. > > >Now, for the full story: I routinely pass the '--enable-strict' option >to configure. According to 'configure --help' this option is supposed to >"Turn on strict compilation testing" which sounds like a good thing when >you are working with unfamiliar code. > >Recently I also started to play around with the '-iface' option of >mpiexec and to my surprise MPICH just produced a rather useless error >message: > > > Fatal error in MPI_Init: Other MPI error" > >A debug build of MPICH 3.0.4 was more informative: > >> Fatal error in MPI_Init: Other MPI error, error stack: >> MPIR_Init_thread(433)..............: >> MPID_Init(176).....................: channel initialization failed >> MPIDI_CH3_Init(70).................: >> MPID_nem_init(286).................: >> MPID_nem_tcp_init(108).............: >> MPID_nem_tcp_get_business_card(354): >> MPID_nem_tcp_init(246).............: The network interface, "eth0", >>specified in MPICH_NETWORK_IFACE was not found. > >To make a long story short, '--enable-strict' apparently passes '-ansi' >to the compiler. The compiler then defines the internal macro >'__STRICT_ANSI__'. On my machine with gcc (Debian 4.7.2-5) 4.7.2 this >will eventually cause 'net/if.h' to hide the definition of 'struct >ifreq' and 'struct ifconf'. > >'configure' detects that these structures are missing and creates an >MPICH build that uses an empty, always-failing version of >'MPIDI_Get_IP_for_iface'. This failure, in turn, results in the >aforementioned rather useless error message. > >IMHO there should either be some mechanism to enable strict code >checking without passing the '-ansi' option or '-iface' should be >disabled cleanly when '--enable-strict' is used. At least some >explanatory error message would be nice ;-) > > >Regards, Jan >_______________________________________________ >discuss mailing list discuss(a)mpich.org >To manage subscription options or unsubscribe: >https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Option '-iface' broken when MPICH is configured with '--enable-strict'
by Balaji, Pavan 06 Feb '14

06 Feb '14

Thank you. I’ve created a ticket for it. On 2/4/14, 3:52 PM, "Jan Bierbaum" <jan.bierbaum(a)tudos.org> wrote: >Hi! > >Although I'm not sure whether this should be considered a bug or just an >annoyance, I thought it would be a good idea to bring it up here because >it took me quiet some time to figure out the underlying problem. > >For those not interested in the details: My suggestion is to disable >'-iface' completely when MPICH is configured with '--enable-strict'. >When the option is used in such a situation, some descriptive error >message should be displayed. > > >Now, for the full story: I routinely pass the '--enable-strict' option >to configure. According to 'configure --help' this option is supposed to >"Turn on strict compilation testing" which sounds like a good thing when >you are working with unfamiliar code. > >Recently I also started to play around with the '-iface' option of >mpiexec and to my surprise MPICH just produced a rather useless error >message: > > > Fatal error in MPI_Init: Other MPI error" > >A debug build of MPICH 3.0.4 was more informative: > >> Fatal error in MPI_Init: Other MPI error, error stack: >> MPIR_Init_thread(433)..............: >> MPID_Init(176).....................: channel initialization failed >> MPIDI_CH3_Init(70).................: >> MPID_nem_init(286).................: >> MPID_nem_tcp_init(108).............: >> MPID_nem_tcp_get_business_card(354): >> MPID_nem_tcp_init(246).............: The network interface, "eth0", >>specified in MPICH_NETWORK_IFACE was not found. > >To make a long story short, '--enable-strict' apparently passes '-ansi' >to the compiler. The compiler then defines the internal macro >'__STRICT_ANSI__'. On my machine with gcc (Debian 4.7.2-5) 4.7.2 this >will eventually cause 'net/if.h' to hide the definition of 'struct >ifreq' and 'struct ifconf'. > >'configure' detects that these structures are missing and creates an >MPICH build that uses an empty, always-failing version of >'MPIDI_Get_IP_for_iface'. This failure, in turn, results in the >aforementioned rather useless error message. > >IMHO there should either be some mechanism to enable strict code >checking without passing the '-ansi' option or '-iface' should be >disabled cleanly when '--enable-strict' is used. At least some >explanatory error message would be nice ;-) > > >Regards, Jan >_______________________________________________ >discuss mailing list discuss(a)mpich.org >To manage subscription options or unsubscribe: >https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] binary for win server 2012
by Kenneth Raffenetti 04 Feb '14

04 Feb '14

Hi, Due to lack of developer resources, MPICH no longer supports the Windows platform. We recommend you use Microsoft MPI, which can be found here: http://msdn.microsoft.com/en-us/library/bb524831(v=vs.85).aspx On 02/04/2014 03:31 PM, mcdougal wrote: > Hello, > > Is there an mpich2 binary package available for Windows Server 2012? > > Thanks, Bill > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] binary for win server 2012
by "Antonio J. Peña" 04 Feb '14

04 Feb '14

Hi Bill, Please refer to our FAQ: http://wiki.mpich.org/mpich/index.php/Frequently_Asked_Questions#Q:_Why_can… Best, Antonio On 02/04/2014 03:31 PM, mcdougal wrote: > Hello, > > Is there an mpich2 binary package available for Windows Server 2012? > > Thanks, Bill > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Antonio J. Peï¿½a Postdoctoral Appointee Mathematics and Computer Science Division Argonne National Laboratory 9700 South Cass Avenue, Bldg. 240, Of. 3148 Argonne, IL 60439-4847 apenya(a)mcs.anl.gov www.mcs.anl.gov/~apenya

1 0

Option '-iface' broken when MPICH is configured with '--enable-strict'
by Jan Bierbaum 04 Feb '14

04 Feb '14

Hi! Although I'm not sure whether this should be considered a bug or just an annoyance, I thought it would be a good idea to bring it up here because it took me quiet some time to figure out the underlying problem. For those not interested in the details: My suggestion is to disable '-iface' completely when MPICH is configured with '--enable-strict'. When the option is used in such a situation, some descriptive error message should be displayed. Now, for the full story: I routinely pass the '--enable-strict' option to configure. According to 'configure --help' this option is supposed to "Turn on strict compilation testing" which sounds like a good thing when you are working with unfamiliar code. Recently I also started to play around with the '-iface' option of mpiexec and to my surprise MPICH just produced a rather useless error message: > Fatal error in MPI_Init: Other MPI error" A debug build of MPICH 3.0.4 was more informative: > Fatal error in MPI_Init: Other MPI error, error stack: > MPIR_Init_thread(433)..............: > MPID_Init(176).....................: channel initialization failed > MPIDI_CH3_Init(70).................: > MPID_nem_init(286).................: > MPID_nem_tcp_init(108).............: > MPID_nem_tcp_get_business_card(354): > MPID_nem_tcp_init(246).............: The network interface, "eth0", specified in MPICH_NETWORK_IFACE was not found. To make a long story short, '--enable-strict' apparently passes '-ansi' to the compiler. The compiler then defines the internal macro '__STRICT_ANSI__'. On my machine with gcc (Debian 4.7.2-5) 4.7.2 this will eventually cause 'net/if.h' to hide the definition of 'struct ifreq' and 'struct ifconf'. 'configure' detects that these structures are missing and creates an MPICH build that uses an empty, always-failing version of 'MPIDI_Get_IP_for_iface'. This failure, in turn, results in the aforementioned rather useless error message. IMHO there should either be some mechanism to enable strict code checking without passing the '-ansi' option or '-iface' should be disabled cleanly when '--enable-strict' is used. At least some explanatory error message would be nice ;-) Regards, Jan

1 0