Re: [OMPI users] VAPI error with mpi_leave_pinned setting
Hi Aniruddha, Are you using the trunk, or one of the release tar files (if so which one). I will try to reproduce this as time permits but I am out of town so please expect some delay. Thanks, Galen > Hi, > > I keep getting a vapi error when running any NAS benchmark on Infiniband > with mpi_leave_pinned option set to 1. This problem does not occur with > mpi_leave_pinned set to 0. Please find attached the error trace. > > Thanks, > Aniruddha > -- > Aniruddha Shet | Project webpage: > http://forge-fre.ornl.gov/molar/index.html > Graduate Research Associate | Project webpage: www.cs.unm.edu/~fastos > Dept. of Comp. Sci. & Engg | Personal webpage: > www.cse.ohio-state.edu/~shet > The Ohio State University | Office: DL 474 > 2015 Neil Avenue | Phone: +1 (614) 292 7036 > Columbus OH 43210-1277 | Cell: +1 (614) 446 1630 > -- > ___ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users
Re: [OMPI users] VAPI error with mpi_leave_pinned setting
On Mon, 24 Apr 2006, Galen Mark Shipman wrote: Hi Galen, I face this problem with releases 1.0.1 and 1.0.2. It probably isn't an issue with Open MPI as there have been instances earlier where setting mpi_leave_pinned to 1 didn't throw up errors. I suspect it is an issue with the compute nodes but cannot confirm for sure. I am also trying to resolve this with the system administrator. Thanks, Aniruddha > Hi Aniruddha, > > Are you using the trunk, or one of the release tar files (if so which one). > I will try to reproduce this as time permits but I am out of town so > please expect some delay. > > Thanks, > > Galen > > > > > Hi, > > > > I keep getting a vapi error when running any NAS benchmark on Infiniband > > with mpi_leave_pinned option set to 1. This problem does not occur with > > mpi_leave_pinned set to 0. Please find attached the error trace. > > > > Thanks, > > Aniruddha > > -- > > Aniruddha Shet | Project webpage: > > http://forge-fre.ornl.gov/molar/index.html > > Graduate Research Associate | Project webpage: www.cs.unm.edu/~fastos > > Dept. of Comp. Sci. & Engg | Personal webpage: > > www.cse.ohio-state.edu/~shet > > The Ohio State University | Office: DL 474 > > 2015 Neil Avenue | Phone: +1 (614) 292 7036 > > Columbus OH 43210-1277 | Cell: +1 (614) 446 1630 > > -- > > ___ > > users mailing list > > us...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/users > > ___ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users > -- - Aniruddha G. Shet | Project webpage: http://forge-fre.ornl.gov/molar/index.html Graduate Research Associate | Project webpage: http://www.cs.unm.edu/~fastos Dept. of Comp. Sci. & Engg | Personal webpage: http://www.cse.ohio-state.edu/~shet The Ohio State University | Office: DL 474 2015 Neil Avenue| Phone: +1 (614) 292 7036 Columbus OH 43210-1277 | Cell: +1 (614) 446 1630 -
[OMPI users] config error
Brain sorry i am enclosing my config.log file tar file here I can not reach to make step Hence can not include it config.log.bz2 Description: Binary data config.out Description: Binary data
[OMPI users] MPI_LONG_LONG_INT != MPI_LONG_LONG
Hi, The current and the previous versions of OpenMPI define MPI_LONG_LONG_INT and MPI_LONG_LONG constants as the address of two distinct global variables (&ompi_mpi_long_long_int and &ompi_mpi_long_long respectively) which makes the following expression true: MPI_LONG_LONG_INT != MPI_LONG_LONG. After consulting the MPI standards, I noticed the following: - The optional datatype corresponding to the optional C/C++ "long long" type is MPI_LONG_LONG_INT according to article 3.2.2. "Message data" of the MPI 1.1 standard (www.mpi-forum.org/docs/mpi-11-html/node32.html) and article 10.2. "Defined Constants for C and Fortran" (www.mpi-forum.org/docs/mpi-11-html/node169.html) of the MPI 1.1 standard. - The MPI_LONG_LONG optional datatype appeared for the first time in section 9.5.2. "External Data Representation: ``external32''" of the MPI 2.0 standard (www.mpi-forum.org/docs/mpi-20-html/node200.htm). This paragraph state that with the external32 data representation, this datatype is eight (8) bytes long. - However the previous statement was recognized as an error in the MPI 2.0 errata document (www.mpi-forum.org/docs/errata-20-2.html). The MPI 2.0 document should have used MPI_LONG_LONG_INT instead of MPI_LONG_LONG. It also state the following: In addition, the type MPI_LONG_LONG should be added as an optional type; it is a synonym for MPI_LONG_LONG_INT. This means that the real optional datatype corresponding to the C/C++ "long long" datatype is MPI_LONG_LONG_INT and that since MPI_LONG_LONG was mentioned by mistake in the MPI 2.0 standard document, the MPI_LONG_LONG predefined datatype constant is also accepted as a synonym to MPI_LONG_LONG_INT. We should therefore have MPI_LONG_LONG_INT == MPI_LONG_LONG which is not the case in OpenMPI. So please have a look at this issue. Note that MPICH and MPICH2 implementations satisfy: MPI_LONG_LONG_INT == MPI_LONG_LONG. Regrards, Martin AudetE: martin DOT audet AT imi cnrc-nrc gc ca Research OfficerT: 450-641-5034 Industrial Material Institute / National Research Council 75 de Mortagne, Boucherville, QC, J4B 6Y4, Canada
Re: [OMPI users] users Digest, Vol 261, Issue 4
> -Original Message- > From: users-boun...@open-mpi.org > [mailto:users-boun...@open-mpi.org] On Behalf Of > laurent.po...@fr.thalesgroup.com > Sent: Friday, April 21, 2006 4:54 AM > To: us...@open-mpi.org > Subject: Re: [OMPI users] users Digest, Vol 261, Issue 4 > > > That being said, we are not opposed to putting port number > controls in > > Open MPI. Especially if it really is a problem for > someone, not just a > > hypothetical problem ;-). But such controls should not be added to > > support firewalled operations, because -- at a minimum -- > unless you do > > a bunch of other firewall configuration, it will not be enough. > > This point is a real problem for me (but I may be the only > one in the world...). > I have to build a system that uses MPI softwares and non MPI COTS. > I can't change TCP ports used by the COTS. > Restricting MPI TCP/UDP port range loks like being the best > solution for me. Ok. Can you describe what you're doing / what you need? If the fear is that you'll conflict with other user-level applications that are using fixed port numbers, you may have this problem with other applications that use dynamic TCP ports as well. Some scenarios may already be handled, too. For example, if you have your user-level, fixed port applications being launched and are guaranteed to be running before the MPI processes are running, then there's no problem (because OMPI -- just like any application that uses dynamic TCP ports -- will only use ports that are not already in use). Or, if your applications are using restricted ports (e.g., below 1024), then OMPI will not conflict because we do not currently use restricted ports. Specifically, I think you only need to restrict OMPI's ports if you want to launch your non-MPI apps that use fixed, non-restricted ports either at the "same" time or after MPI apps are launched, then I can see how this would be necessary (although the chances of a collision are pretty small, they are nonzero). Indeed, with a quick peek in /etc/services, I see a fair number of services that have port numbers >1024 (subversion, postgres, finger, ...etc.). It strikes me that many (all?) of these fit the "will be launched at boot up time, so even though they're not in the restricted range, they'll be the first ones to ask for that port and therefore there's no problem" category. My point here: there's precedent for this model. Does that help? Or do you still need TCP port restrictions? -- Jeff Squyres Server Virtualization Business Unit Cisco Systems
Re: [OMPI users] MPI_LONG_LONG_INT != MPI_LONG_LONG
I miss that part of the MPI 2 errata. I made the corrections, now MPI_LONG_LONG and MPI_LONG_LONG_INT are identical. Therefore one will have MPI_LONG_LONG == MPI_LONG_LONG_INT. You can use it from the trunk starting from revision 9701. It will be back-ported on the 1.1 and 1.0.3 on the next days. Thanks, george. On Apr 24, 2006, at 3:20 PM, Audet, Martin wrote: Hi, The current and the previous versions of OpenMPI define MPI_LONG_LONG_INT and MPI_LONG_LONG constants as the address of two distinct global variables (&ompi_mpi_long_long_int and &ompi_mpi_long_long respectively) which makes the following expression true: MPI_LONG_LONG_INT != MPI_LONG_LONG. After consulting the MPI standards, I noticed the following: - The optional datatype corresponding to the optional C/C++ "long long" type is MPI_LONG_LONG_INT according to article 3.2.2. "Message data" of the MPI 1.1 standard (www.mpi-forum.org/docs/ mpi-11-html/node32.html) and article 10.2. "Defined Constants for C and Fortran" (www.mpi-forum.org/docs/mpi-11-html/node169.html) of the MPI 1.1 standard. - The MPI_LONG_LONG optional datatype appeared for the first time in section 9.5.2. "External Data Representation: ``external32''" of the MPI 2.0 standard (www.mpi-forum.org/docs/mpi-20-html/ node200.htm). This paragraph state that with the external32 data representation, this datatype is eight (8) bytes long. - However the previous statement was recognized as an error in the MPI 2.0 errata document (www.mpi-forum.org/docs/errata-20-2.html). The MPI 2.0 document should have used MPI_LONG_LONG_INT instead of MPI_LONG_LONG. It also state the following: In addition, the type MPI_LONG_LONG should be added as an optional type; it is a synonym for MPI_LONG_LONG_INT. This means that the real optional datatype corresponding to the C/C+ + "long long" datatype is MPI_LONG_LONG_INT and that since MPI_LONG_LONG was mentioned by mistake in the MPI 2.0 standard document, the MPI_LONG_LONG predefined datatype constant is also accepted as a synonym to MPI_LONG_LONG_INT. We should therefore have MPI_LONG_LONG_INT == MPI_LONG_LONG which is not the case in OpenMPI. So please have a look at this issue. Note that MPICH and MPICH2 implementations satisfy: MPI_LONG_LONG_INT == MPI_LONG_LONG. Regrards, Martin AudetE: martin DOT audet AT imi cnrc-nrc gc ca Research OfficerT: 450-641-5034 Industrial Material Institute / National Research Council 75 de Mortagne, Boucherville, QC, J4B 6Y4, Canada ___ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users "Half of what I say is meaningless; but I say it so that the other half may reach you" Kahlil Gibran
Re: [OMPI users] SIGBUS on sparc / 64bit
On Apr 21, 2006, at 3:26 AM, Alexander Spiegel wrote: I'm trying to compile OpenMPI 1.0.2 on a Sparc/Solaris machine with Sun Studio 11 compilers in 64 bit addressing mode. t@1 (l@1) signal BUS (invalid address alignment) in mca_allocator_bucket_alloc_align at line 206 in file "allocator_bucket_alloc.c" 206 chunk = segment_header->first_chunk = first_chunk; Thanks for the bug report. I committed a fix to our development trunk and it will be back-ported to our release branches (both 1.0 and 1.1 series of releases). I believe the maintainer of the 1.0 branch moved the change over to the branch already, so it should show up in the nightly tarballs starting tomorrow (Tuesday), and are available here: http://www.open-mpi.org/nightly/v1.0/ Brian -- Brian Barrett Open MPI developer http://www.open-mpi.org/
