November 2015 - discuss - mailman3.cels.anl.gov

MPICH 3.1.4 Behavior
by Daniel Buchwieser da Silva 09 Nov '15

09 Nov '15

Good morning I have a problem with the version 3.1.4 MPICH when I try to execute a program across different machines with multiples processors. The error is showed below someone have ever seen this error or resolved then? Fatal error in MPI_Bcast: Other MPI error, error stack: MPI_Bcast(786)..............................: MPI_Bcast(buf=0x1d2af88, count=1, MPI_INTEGER, root=0, MPI_COMM_WORLD) failed MPIR_Bcast(230).............................: MPIC_Send(39)...............................: MPIC_Wait(270)..............................: MPIDI_CH3i_Progress_wait(215)...............: an error occurred while handling an event returned by MPIDU_Sock_Wait() MPIDI_CH3I_Progress_handle_sock_event(779)..: MPIDI_CH3_Sockconn_handle_connect_event(608): [ch3:sock] failed to connnect to remote process MPIDU_Socki_handle_connect(795).............: connection failure (set=0,sock=1,errno=111:Connection refused)[cli_0]: aborting job: Fatal error in MPI_Bcast: Other MPI error, error stack: MPI_Bcast(786)..............................: MPI_Bcast(buf=0x1d2af88, count=1, MPI_INTEGER, root=0, MPI_COMM_WORLD) failed MPIR_Bcast(230).............................: MPIC_Send(39)...............................: MPIC_Wait(270)..............................: MPIDI_CH3i_Progress_wait(215)...............: an error occurred while handling an event returned by MPIDU_Sock_Wait() MPIDI_CH3I_Progress_handle_sock_event(779)..: MPIDI_CH3_Sockconn_handle_connect_event(608): [ch3:sock] failed to connnect to remote process MPIDU_Socki_handle_connect(795).............: connection failure (set=0,sock=1,errno=111:Connection refused) Daniel Buchwieser da Silva Analista de Informática U.O. Sistemas de Informação e Telecomunicação-DSI Fone: +55 +55 (48) 3221-7311 danielbs(a)tractebelenergia.com.br http://www.tractebelenergia.com.br Antes de imprimir, pense em sua responsabilidade e compromisso com o MEIO AMBIENTE. Before printing, think about your ENVIRONMENTAL responsibility. Aviso Legal: Esta mensagem é para uso exclusivo do(s) destinatário(s) indicado(s) e pode conter informações protegidas por segredo profissional, por direitos do autor ou por outras normas legais. Se você a recebeu por engano, por favor, comunique-nos mediante resposta e a elimine de seus sistemas. É proibido copiar ou revelar o seu conteúdo a qualquer outra pessoa. A confidencialidade e o segredo profissional legal não são diminuídos ou invalidados por qualquer envio equivocado desta mensagem. Todas as mensagens enviadas a/por esta Companhia podem ser controladas e monitoradas para garantir o cumprimento das políticas internas, para proteger os interesses da Companhia e para eliminar softwares mal intencionados (malware). No entanto, as mensagens eletrônicas não são seguras e podem conter erros, ser interceptadas, modificadas, perdidas, eliminadas ou conter algum tipo de vírus. Qualquer pessoa que se comunica com nossa Companhia por correio eletrônico aceita esses riscos. As delegações de poderes e de autoridade devem ser verificadas e estão disponíveis mediante solicitação. Disclaimer: This message is for the sole use of the intended recipient(s) and may have privileged information or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply and delete it from your systems. It is forbidden to copy it or disclose its content to anyone. Any confidentiality or legal professional privilege is not waived or lost by any mistaken delivery of the message. All messages sent to and from this company may be monitored to ensure compliance with internal policies, to protect the company's interests and to remove potential malware. However, electronic messages are not secure nor error free as they can be intercepted, amended, lost or deleted, or contain viruses. Anyone who communicates with our company by electronic messaging accepts these risks. Delegations of power and authority have to be verified and are available upon request. _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

AUTOMÁTICO: Daniel Silva está ausente do escritório. (retorna em 22/11/2015)
by Daniel Buchwieser da Silva 07 Nov '15

07 Nov '15

Estarei ausente do escritório até 22/11/2015 Favor tratar os seguintes assuntos conforme abaixo: OS JAVA: Cleiton de Souza Bertoli ou Otavio José Nicolau OS Dot.Net Otavio José Nicolau Opmon: Michel Perez Notes: Taiane dos Santos Gonçalves Sistema Maximo: Orlando ou Taiane dos Sanatos Gonçalves. Newave: Allan Keller ou Eric Follmann Demais assuntos serão retomados ao meu retorno. Obrigado e att. Daniel B. da Silva Nota: esta é uma resposta automática à sua mensagem "Re: [mpich-discuss] [Fwd: MPI_File_read_at_all external32 bug in MV2-2.1]" enviado em 06/11/2015 23:13:08. Esta é a única notificação que você receberá enquanto esta pessoa estiver ausente.

1 0

Re: [mpich-discuss] [Fwd: MPI_File_read_at_all external32 bug in MV2-2.1]
by Balaji, Pavan 06 Nov '15

06 Nov '15

Adam, Not yet. We were working heads-down on the mpich-3.2 release. I'm adding the mpich discuss list to cc, and poking @robl as well. Do you have a test program that reproduces the error? (sorry if you already sent it, I'm still catching up on the pending issues). -- Pavan > On Nov 6, 2015, at 2:10 PM, Adam T. Moody <moody20(a)llnl.gov> wrote: > > Hi Pavan, > Did you have a chance to look into this in MPICH? > > I'm pretty certain there is a lurking ROMIO bug here. > -Adam > > > Adam T. Moody wrote: > >> Hi Pavan and Howard, >> FYI, it looks this same bug is in MPICH-3.2rc1 and Open MPI-1.10.0. >> >> I guess no one uses collective I/O with external32 :-) >> -Adam >> >> ------------------------------------------------------------------------ >> >> Subject: >> MPI_File_read_at_all external32 bug in MV2-2.1 >> From: >> "Adam T. Moody" <moody20(a)llnl.gov> >> Date: >> Fri, 30 Oct 2015 11:48:35 -0700 >> To: >> "mvapich-discuss(a)cse.ohio-state.edu" <mvapich-discuss(a)cse.ohio-state.edu> >> >> To: >> "mvapich-discuss(a)cse.ohio-state.edu" <mvapich-discuss(a)cse.ohio-state.edu> >> >> >> Hello MVAPICH team, >> I've hit a bug in MPI_File_read_at_all in MVAPICH2-2.1. I have an application that reads and writes files in external32 format. It writes the file just fine, but it throws the following error when reading the file back: >> >> internal ABORT - process 0 >> srun: error: rzmerl2: task 0: Exited with exit code 1 >> Assertion failed in file src/mpid/common/datatype/mpid_ext32_segment.c at line 277: FALSE >> memcpy argument memory ranges overlap, dst_=0x2aaab5c160a8 src_=0x2aaab5c160a8 len_=176 >> >> Above, MPI is trying to do a memcpy where the source and destination buffer are the same address. Looking through the code for MVAPICH2-2.1, the problem seems to be at line 132 in src/mpi/romio/mpi-io/read_all.c: >> >> if (e32_buf != NULL) { >> error_code = MPIU_read_external32_conversion_fn(xbuf, datatype, >> count, e32_buf); >> ADIOI_Free(e32_buf); >> } >> >> I think the fix is to change "xbuf" above to "buf" as it is in read.c below: >> >> if (e32_buf != NULL) { >> error_code = MPIU_read_external32_conversion_fn(buf, datatype, >> count, e32_buf); >> ADIOI_Free(e32_buf); >> } >> >> When in external32 mode, xbuf == e32_buf, which acts as a temporary buffer in which to read the data. The code is then meant to unpack and convert the data from the temporary buffer into the user buffer at buf. >> >> It's probably worth checking the other external32 code paths to look for similar bugs. >> Thanks, >> -Adam >> >

1 0

Announcing the availability of mpich-3.2rc2
by Kenneth Raffenetti 04 Nov '15

04 Nov '15

The MPICH team is pleased to announce the availability of a new preview release (mpich-3.2rc2). This is a release candidate of the upcoming MPICH 3.2. This preview release addresses bugs that were present in the previous release candidate. Unless other critical bugs are found, this release would be identical to the final 3.2 GA release (apart from the version number change). http://www.mpich.org A list of changes in this release is included at the end of this email. Regards, The MPICH Team =============================================================================== Changes in 3.2 =============================================================================== # Added support for MPI-3.1 features including nonblocking collective I/O, address manipulation routines, thread-safety for MPI initialization, pre-init functionality, and new MPI_T routines to look up variables by name. # Fortran 2008 bindings are enabled by default and fully supported. # Added support for the Mellanox MXM InfiniBand interface. (thanks to Mellanox for the code contribution). # Added support for the Mellanox HCOLL interface for collectives. (thanks to Mellanox for the code contribution). # Significant stability improvements to the MPICH/portals4 implementation. # Completely revamped RMA infrastructure including several scalability improvements, performance improvements, and bug fixes. # Added experimental support for Open Fabrics Interfaces (OFI) version 1.0.0. https://github.com/ofiwg/libfabric (thanks to Intel for code contribution) # The Myrinet MX network module, which had a life cyle from 1.1 till 3.1.2, has now been deleted. # Several other minor bug fixes, memory leak fixes, and code cleanup. A full list of changes is available at the following link: http://git.mpich.org/mpich.git/shortlog/v3.1.3..v3.2rc2 A full list of bugs that have been fixed is available at the following link: https://trac.mpich.org/projects/mpich/query?status=closed&group=resolution&… _______________________________________________ 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] handling illegal values in --enable-error-messages
by Sayan Ghosh 02 Nov '15

02 Nov '15

Thanks Halim, understood. //Sayan On Mon, Nov 2, 2015 at 10:59 AM, Halim Amer <aamer(a)anl.gov> wrote: > Sayan, > > Configure options given at the root directory are propagated to the > sub-directories that contain some independent components (in the sense they > can have a standalone build) such as Hydra, ROMIO, OpenPA and so on. These > components may have their own options and may not need some MPICH-core > options. So, detecting illegal options at the root level is difficult and > not supported at the current state. That's why you can pass illegal options > and only detect them a complication time. > > --Halim > www.mcs.anl.gov/~aamer > > > On 11/2/15 12:34 PM, Sayan Ghosh wrote: > >> Hi, >> >> I noticed that if I pass something illegal to >> --enable-error-messages=<>, then configure just throws a warning and >> continues, but the build fails during compilation. Not sure if this is >> intended, so just reporting. >> >> src/mpi/attr/attrutil.c(99): error: expected an expression >> #if MPICH_ERROR_MSG_LEVEL < MPICH_ERROR_MSG_ALL >> ^ >> >> src/mpi/attr/attrutil.c(159): error: expected an expression >> #if MPICH_ERROR_MSG_LEVEL < MPICH_ERROR_MSG_ALL >> >> >> -- >> Regards, >> Sayan >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> >> _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Regards, Sayan _______________________________________________ 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] handling illegal values in --enable-error-messages
by Halim Amer 02 Nov '15

02 Nov '15

Sayan, Configure options given at the root directory are propagated to the sub-directories that contain some independent components (in the sense they can have a standalone build) such as Hydra, ROMIO, OpenPA and so on. These components may have their own options and may not need some MPICH-core options. So, detecting illegal options at the root level is difficult and not supported at the current state. That's why you can pass illegal options and only detect them a complication time. --Halim www.mcs.anl.gov/~aamer On 11/2/15 12:34 PM, Sayan Ghosh wrote: > Hi, > > I noticed that if I pass something illegal to > --enable-error-messages=<>, then configure just throws a warning and > continues, but the build fails during compilation. Not sure if this is > intended, so just reporting. > > src/mpi/attr/attrutil.c(99): error: expected an expression > #if MPICH_ERROR_MSG_LEVEL < MPICH_ERROR_MSG_ALL > ^ > > src/mpi/attr/attrutil.c(159): error: expected an expression > #if MPICH_ERROR_MSG_LEVEL < MPICH_ERROR_MSG_ALL > > > -- > Regards, > Sayan > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

handling illegal values in --enable-error-messages
by Sayan Ghosh 02 Nov '15

02 Nov '15

Hi, I noticed that if I pass something illegal to --enable-error-messages=<>, then configure just throws a warning and continues, but the build fails during compilation. Not sure if this is intended, so just reporting. src/mpi/attr/attrutil.c(99): error: expected an expression #if MPICH_ERROR_MSG_LEVEL < MPICH_ERROR_MSG_ALL ^ src/mpi/attr/attrutil.c(159): error: expected an expression #if MPICH_ERROR_MSG_LEVEL < MPICH_ERROR_MSG_ALL -- Regards, Sayan _______________________________________________ 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] online docs not found
by Thakur, Rajeev 02 Nov '15

02 Nov '15

NFS problem over the weekend. > On Nov 2, 2015, at 10:40 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > As of last week, I had no trouble finding the MPICH docs online. This morning, when I go to e.g. http://www.mpich.org/static/docs/v3.1/www3/MPI_Alloc_mem.html, I see this: > Not Found > > The requested URL /static/docs/v3.1/www3/MPI_Alloc_mem.html was not found on this server. > > Is this a transient error or did something change on your website? > > Thanks, > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

online docs not found
by Jeff Hammond 02 Nov '15

02 Nov '15

As of last week, I had no trouble finding the MPICH docs online. This morning, when I go to e.g. http://www.mpich.org/static/docs/v3.1/www3/MPI_Alloc_mem.html, I see this: Not Found The requested URL /static/docs/v3.1/www3/MPI_Alloc_mem.html was not found on this server. Is this a transient error or did something change on your website? Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/ _______________________________________________ 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] long message testing in MPICH test suite
by Kenneth Raffenetti 02 Nov '15

02 Nov '15

Just closing the loop on this issue. Through side-channel discussions, we modified the patch and included it in the latest mpich/master branch. Ken On 10/30/2015 12:22 PM, Rusty Lusk wrote: > In a recent exchange with the OSU folks, it was discovered that there is > a gap in the MPICH test suite in that the code that tests for the > correctness of handling long messages forgets to test that count is > handled correctly. This led to the escape of a bug in the MVAPICH code, > since corrected. Hari tracked this down and has sent a patch. Could > the MPICH team look at this? > > Thanks, > Rusty > > Begin forwarded message: > >> *From: *Hari Subramoni <subramoni.1(a)osu.edu <mailto:[email protected]>> >> *Subject: **Re: [lcrc-support #279383] Re: Long messages* >> *Date: *October 26, 2015 at 12:19:42 PM CDT >> *To: *Rusty Lusk <lusk(a)mcs.anl.gov <mailto:[email protected]>> >> *Cc: *"Low, John J." <jlow(a)mcs.anl.gov <mailto:[email protected]>>, >> Steve Pieper <spieper(a)anl.gov <mailto:[email protected]>>, "Wiringa, >> Robert B." <wiringa(a)anl.gov <mailto:[email protected]>>, "D.K. Panda" >> <panda(a)cse.ohio-state.edu <mailto:[email protected]>>, >> "support(a)lcrc.anl.gov <mailto:[email protected]>" >> <support(a)lcrc.anl.gov <mailto:[email protected]>>, "Balaji, Pavan" >> <balaji(a)anl.gov <mailto:[email protected]>> >> >> Hello All, >> >> I was investigating to see how this was missed earlier. In our MPICH >> large-message test (test/mpi/pt2pt/large_message.c) which should've >> caught this, the code which tests the result of MPI_Get_count was missing. >> >> I was checking the large_message.c test that is shipped with >> MPICH-3.1.4 (latest stable) and MPICH-3.2rc1 (preview release) >> available from the MPICH site. Both have the same issue. The >> large-message-test.patch should fix this. >> >> If the patch looks good, it would be good if this gets applied to >> MPICH itself so that all MPICH derivatives can benefit from it. >> >> Best Regards, >> Hari. >> > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0