Hi again,
I have a follow-up question. I have been using MPI_Init_thread and
MPI_Isend/MPI_Irecv/MPI_Waitany for a while now and have stubled over
what may be a but in MPI_Waitany...
Within a parallel region of the code (in this case I am using OpenMP),
calls to MPI_Isend and MPI_Irecv work find
Sorry for the delay.
I will try with the MPI_ERRORS_RETURN handler, maybe that is my problem.
Thanks a lot for your help.
I'll let you know how it goes.
Best regards.
Hugo
2011/12/16 George Bosilca
> Setting the error handler to MPI_ERRORS_RETURN is the right solution for
> mechanism using th
On Dec 16, 2011, at 7:39 PM, Paul H. Hargrove wrote:
> I've noticed that on, for instance, FreeBSD I must compile openmpi-1.5.5rc1
> with "gmake" rather than "make".
> I didn't see "GNU Make" listed as a build dependency in the README, and so I
> wonder if this was known.
>
> The failure mode s
On 12/20/2011 1:51 PM, Jeff Squyres wrote:
On Dec 16, 2011, at 7:39 PM, Paul H. Hargrove wrote:
I've noticed that on, for instance, FreeBSD I must compile openmpi-1.5.5rc1 with "gmake"
rather than "make".
I didn't see "GNU Make" listed as a build dependency in the README, and so I
wonder if
I'm technically not working this week, but spot-checked my email to see where
we are with v1.5 (shh! don't tell my wife...)
1. There are a number of outstanding issues such that it does not seem like it
is a good idea to rush out a v1.5 release just so that we can say it was before
the holidays
While trying to resolve the gmake-vs-bmake problem I ran autogen.sh and saw:
/home/phargrov/OMPI/openmpi-1.5.5rc1/openmpi-1.5.5rc1/autogen.sh: line
701: config/modify-configure-for-sun-fortran.pl: No such file or directory
I suspect this just requires an addition to EXTRA_DIST in config/Makefi
Of course that subject should have said "1.5.*5*rc1" rather than "1.5.1rc1"
On 12/20/2011 3:22 PM, Paul H. Hargrove wrote:
While trying to resolve the gmake-vs-bmake problem I ran autogen.sh
and saw:
/home/phargrov/OMPI/openmpi-1.5.5rc1/openmpi-1.5.5rc1/autogen.sh: line
701: config/modify-con
On Dec 20, 2011, at 6:20 PM, Jeff Squyres wrote:
> 2. Here are the issues that I am aware of:
>
> - VT build issues; they just filed a CMR today that may or may not be complete
> - shmem segv errors; Sam and Ralph are iterating on this and seem to be
> closing in on a fix
> - debugger issues; Na
Yeah, we've known about this one and mostly ignored it.
It occurs when autogen.sh is in a non-root directory and tries to run that
script in a place where it doesn't exist (it does exist in the root directory).
We hadn't previously bothered to fix it because a) it's in autogen and users
won't
On 12/20/2011 2:47 PM, Paul H. Hargrove wrote:
[snip]
So, conclusions:
1) On line 16 of generate-asm.pl, "$1" is a typo for "$!", but is NOT
the true problem.
2) Somebody who knows automake is going to have to rework the
"generated/@OMPI_ASM_FILE@" target in opal/asm/Makefile.am to work
corre
Regardless of any other issues the referenced file does not appear in
the tarball at all:
$ tar tfj openmpi-1.5.5rc1.tar.bz2 | grep
modify-configure-for-sun-fortran.pl || echo NOPE
NOPE
-Paul
On 12/20/2011 3:30 PM, Jeff Squyres wrote:
Yeah, we've known about this one and mostly ignored it.
Here's a trivial patch that seems to fix it:
Index: autogen.sh
===
--- autogen.sh (revision 25674)
+++ autogen.sh (working copy)
@@ -698,7 +698,9 @@
rm -f configure.patched
echo " ++ Modifying configure for Sun Studio Fo
Interesting - I'll fix it. Thanks!
On Dec 20, 2011, at 4:40 PM, Paul H. Hargrove wrote:
> Regardless of any other issues the referenced file does not appear in the
> tarball at all:
>
> $ tar tfj openmpi-1.5.5rc1.tar.bz2 | grep modify-configure-for-sun-fortran.pl
> || echo NOPE
> NOPE
>
> -Pa
You are quite correct - it was indeed missing from Makefile.am! Fixed - and
thanks!
On Dec 20, 2011, at 4:40 PM, Paul H. Hargrove wrote:
> Regardless of any other issues the referenced file does not appear in the
> tarball at all:
>
> $ tar tfj openmpi-1.5.5rc1.tar.bz2 | grep modify-configure-
I checked the wait_any code, and I can only see one possible execution path to
return MPI_UNDEFINED. All requests have to be marked as inactive, which only
happens after the OMPI request completion function is called.
This lead to the following question. Are your threads waiting on common
reque
I will be "offline" Dec 23 to Jan 2, and thus unable to retest any rc2
appearing in that interval against the several issues I reported.
"My" issues include at least:
+ 2 VT issues (both header related), one on BSD systems only the other
on Solaris10 only
+ the hwloc generated config.h, on no
You are welcome.
NOTE: the same issue exists in 1.4.5rc1
$ grep for-sun-fortran openmpi-1.4.5rc1/autogen.sh
config/modify-configure-for-sun-fortran.pl
$ tar tfj openmpi-1.4.5rc1.tar.bz2 | grep
modify-configure-for-sun-fortran.pl || echo NOPE
NOPE
-Paul
On 12/20/2011 3:55 PM, Ralph Castain
Bizarre - fixed it too, but no promise when that might appear in a release.
Thanks!
On Dec 20, 2011, at 5:10 PM, Paul H. Hargrove wrote:
> You are welcome.
> NOTE: the same issue exists in 1.4.5rc1
>
> $ grep for-sun-fortran openmpi-1.4.5rc1/autogen.sh
>config/modify-configure-for-sun-fortr
For the first time I tried "make clean" on FreeBSD and found /another/
GNU-vs-Berkeley Make problem.
The problem is use of $(RM) in several Makefile.am's (see below for list).
The onlt non-VT instance (ompi_info/Makefile.am) occurs in
openmpi-1.4.5rc1 as well.
$(RM) is a predefined variable i
Not too bizarre.
This probably just means that nobody has ever run autogen.sh from a
tarball on a system using Sun's FORTRAN compiler.
-Paul
On 12/20/2011 5:01 PM, Ralph Castain wrote:
Bizarre - fixed it too, but no promise when that might appear in a release.
Thanks!
On Dec 20, 2011, at 5:
:-)
We usually do a better job of ensuring files are properly included in the
tarball, though
On Dec 20, 2011, at 6:21 PM, Paul H. Hargrove wrote:
> Not too bizarre.
> This probably just means that nobody has ever run autogen.sh from a tarball
> on a system using Sun's FORTRAN compiler.
>
> I am pretty sure a literal "rm -rf" should be fine.
Not necessarily. I'm not at work. But I think either -f or -r might not be
legal on all Unix's (Tru64 Unix? AIX?).
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On Dec 20, 2011, at 5:19 PM, Paul H. Hargrove wrote:
> For
On Tue, Dec 20, 2011 at 8:28 PM, Larry Baker wrote:
>> I am pretty sure a literal "rm -rf" should be fine.
>
> Not necessarily. I'm not at work. But I think either -f or -r might not be
> legal on all Unix's (Tru64 Unix? AIX?).
I used to code on AIX daily, and I am pretty sure that "rm -rf" w
OK, I'll concede the "-r" which should not be required in this case anyway.
However, if "rm -f" doesn't work, then we have 169 additional problems
to fix ;-)
$ find openmpi-1.5.5rc1 -name Makefile.am | xargs grep 'rm -f' | wc -l
169
-Paul
On 12/20/2011 5:28 PM, Larry Baker wrote:
I am pr
Quoting from the the autoconf docs at
http://www.gnu.org/s/hello/manual/autoconf/Limitations-of-Usual-Tools.html#Limitations-of-Usual-Tools
rm
The -f and -r options are portable.
-Paul
On 12/20/2011 5:40 PM, Rayson Ho wrote:
On Tue, Dec 20, 2011 at 8:28 PM, Larry Baker wrote:
I a
While dealing w/ GNU-vs-Berkeley Make issues, mentioned in passing that
I wasn't able to autogen on my FreeBSD tester because the resulting
configure failed. The specific failure I encountered was:
configure: error: No atomic primitives available for
amd64-unknown-freebsd8.2
The problem boils
26 matches
Mail list logo
