Creating nightly hwloc snapshot SVN tarball was a success.
Snapshot: hwloc 1.3.2rc1r4239
Start time: Wed Feb 1 21:07:33 EST 2012
End time: Wed Feb 1 21:11:03 EST 2012
Your friendly daemon,
Cyrador
Creating nightly hwloc snapshot SVN tarball was a success.
Snapshot: hwloc 1.4.1a1r4238
Start time: Wed Feb 1 21:04:23 EST 2012
End time: Wed Feb 1 21:07:33 EST 2012
Your friendly daemon,
Cyrador
Creating nightly hwloc snapshot SVN tarball was a success.
Snapshot: hwloc 1.5a1r4237
Start time: Wed Feb 1 21:01:02 EST 2012
End time: Wed Feb 1 21:04:23 EST 2012
Your friendly daemon,
Cyrador
Updates as of 17:30 US Pacific time
On 2/1/2012 1:45 PM, Paul H. Hargrove wrote:
The following two remain, as far as I know, UNRESOLVED:
+ hwloc-1.3.1 "gmake check" failure on Solaris-10/SPARC/gccfss
http://www.open-mpi.org/community/lists/hwloc-devel/2012/01/2729.php
For this compiler the ffs
On 2/1/2012 11:46 AM, Paul H. Hargrove wrote:
[snip]
So, in short: when building w/ this compiler, hwloc needs to behave as
if the system lacks ffs().
Making that happen is non-trivial because there are no preprocessor
symbols defined by gccfss that would allow compile-time #if checks to
dis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/02/12 10:38, Paul H. Hargrove wrote:
> With that out of the way, I am please to say that when configuring
> hwloc-1.3.1 with "CFLAGS=-qhalt=e" the correct variant of
> sched_setaffinity() is detected. This gets rid of the messages
> regarding s
On 2/1/2012 4:14 PM, Christopher Samuel wrote:
On 02/02/12 10:38, Paul H. Hargrove wrote:
> I am not sure if one should fix this by:
> a) Document the need for CFLAGS=-qhalt=e
> b) Force "-qhalt=e" at configure time when CC=xlc
> c) Find some other way to fix the configure probe
>
> My
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/02/12 10:38, Paul H. Hargrove wrote:
> I am not sure if one should fix this by:
> a) Document the need for CFLAGS=-qhalt=e
> b) Force "-qhalt=e" at configure time when CC=xlc
> c) Find some other way to fix the configure probe
>
> My vote is fo
On 2/1/2012 3:12 PM, Paul H. Hargrove wrote:
[...]
This is WRONG.
The compiler has reported an error: "(E) Missing argument(s)" and yet
exited with $? = 0
I am looking at xlc docs to see if there is some compiler flag to be set.
From "man xlc":
-qhalt=
Stops the com
We crossed in the ether about 1 minute apart :-)
On 2/1/2012 3:15 PM, Brice Goglin wrote:
Thanks for the debugging, this makes my last mail to Christopher useless
then:)
Brice
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department
Le 02/02/2012 00:12, Paul H. Hargrove a écrit :
>
>
> On 2/1/2012 5:20 AM, Brice Goglin wrote:
>> Le 01/02/2012 03:49, Christopher Samuel a écrit :
>>> With XLC and 1.3.1 and 1.4 I get plenty of warnings (compile logs for
>>> both attached) whilst compiling and then 4 failures in make check
>>> (ac
Le 01/02/2012 23:59, Christopher Samuel a écrit :
> On 02/02/12 00:20, Brice Goglin wrote:
>
> > This looks very bad. It means something screwed the already very complex
> > sched_setaffinity detection code.
> > Does XLC redefine its own sched_setaffinity functions? Can you find the
> > relevant he
On 2/1/2012 5:20 AM, Brice Goglin wrote:
Le 01/02/2012 03:49, Christopher Samuel a écrit :
With XLC and 1.3.1 and 1.4 I get plenty of warnings (compile logs for
both attached) whilst compiling and then 4 failures in make check
(accompanied with segmentation faults):
samuel@tambo:~/HWLOC/hwloc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/02/12 00:20, Brice Goglin wrote:
> This looks very bad. It means something screwed the already very complex
> sched_setaffinity detection code.
> Does XLC redefine its own sched_setaffinity functions? Can you find the
> relevant header file and
The topology of the virtual node is a bit unusual, I am reproducing a
similar setup with Linux cgroups. I already found some problems there,
no idea if they are related to yours, we'll see when I'll have some patches.
Brice
Le 01/02/2012 21:07, Paul H. Hargrove a écrit :
> Responses intersperse
A status report as of 13:30 US Pacific time.
Note that all the bugs I reported last night appeared in BOTH 1.3.1 and
1.4 (despite only 1.3.1 in the initial subject lines of each thread).
With the tarball which Jeff Squyres provided off-list I've verified that
the bugs in the following threads
On 2/1/2012 1:06 AM, Brice Goglin wrote:
Le 01/02/2012 03:52, Paul H. Hargrove a écrit :
...c343//hwloc-1.3.1/doc/doxygen-doc/man/man3/HWLOC_OBJ_PU.3
/export/home
/phargrov/O
'/export/home/phargrov/OMPI/hwloc-1.3.1-solaris10-x86-gcc343/INST/share/man/man3'
/export/home/phargrov/OMPI/hwloc-1.3.
I can confirm this appears to be fixed in the "1.5a1r4236M" tarball
which Jeff provided off-list.
-Paul
On 2/1/2012 4:47 AM, Brice Goglin wrote:
Thanks, this should be fixed in trunk>= r4230, I'll backport in other
branches soon. We didn't need add -lm for fabs() because gcc uses an
intrinsics,
Schweet. I'll commit to the trunk and back port to 1.3 and 1.4.
(we had some off-list emails coordinating the testing of this one; Paul is
referring to a test tarball that I sent to him)
On Feb 1, 2012, at 3:57 PM, Paul H. Hargrove wrote:
> I can confirm this appears to be fixed in the "1.5a1r
I can confirm this appears to be fixed in the "1.5a1r4236M" tarball
which Jeff provided.
-Paul
On 1/31/2012 11:46 PM, Brice Goglin wrote:
I fixed this one, thanks.
Brice
Le 01/02/2012 03:50, Paul H. Hargrove a écrit :
The problem I described below is ALSO present in hwloc-1.4
-Paul
On 1/3
I think that bug report does apply, but the fix they suggest (after
adding the missing "return") does NOT.
I added the following 4 lines to the bottom of hwloc-1.4/src/misc.c:
#if 1 /* XXX: replace '1' with a probe for gccfss */
#include
int __ffssi2 (int x) { return ffs(x); }
#endif
And recon
On 2/1/2012 9:13 AM, Samuel Thibault wrote:
Paul H. Hargrove, le Wed 01 Feb 2012 05:58:05 +0100, a écrit :
At the moment my suspicion falls on the compiler, as I can't see how a
failure of 256ia64-64n2s2c.output could be h/w dependent.
It could be a problem of imperfect qemu emulation.
Samue
Brice Goglin, le Wed 01 Feb 2012 14:02:53 +0100, a écrit :
> Any idea why this broke FreeBSD?
> http://hydra.bordeaux.inria.fr/build/22112 (same problem for tunk and v1.4)
> Brice
Oops, I had forgottent about the redzone. Should be fixed now.
Samuel
Paul H. Hargrove, le Wed 01 Feb 2012 05:58:05 +0100, a écrit :
> At the moment my suspicion falls on the compiler, as I can't see how a
> failure of 256ia64-64n2s2c.output could be h/w dependent.
It could be a problem of imperfect qemu emulation.
Samuel
Can you run hwloc-gather-topology and send the resulting tarball and
output ?
We've seen some powerpc machines where the old kernel didn't say much
about the topology, so your 8 cores with 4 threads appeared as 32 things
without much details about their organization. I assume you can't
upgrade the
Le 01/02/2012 03:49, Christopher Samuel a écrit :
> With XLC and 1.3.1 and 1.4 I get plenty of warnings (compile logs for
> both attached) whilst compiling and then 4 failures in make check
> (accompanied with segmentation faults):
>
> samuel@tambo:~/HWLOC/hwloc-1.3.1> grep -B1 FAIL: log
> /bin/sh:
Any idea why this broke FreeBSD?
http://hydra.bordeaux.inria.fr/build/22112 (same problem for tunk and v1.4)
Brice
Le 31/01/2012 17:36, sthib...@osl.iu.edu a écrit :
> Author: sthibaul
> Date: 2012-01-31 11:36:23 EST (Tue, 31 Jan 2012)
> New Revision: 4224
> URL: https://svn.open-mpi.org/trac/hw
Thanks, this should be fixed in trunk >= r4230, I'll backport in other
branches soon. We didn't need add -lm for fabs() because gcc uses an
intrinsics, and libxml2 depends on libm, quite lucky.
Brice
Le 01/02/2012 03:48, Paul H. Hargrove a écrit :
> The problem I described below is ALSO present
Does this bug report apply?
https://forums.oracle.com/forums/thread.jspa?threadID=1997328
Brice
Le 01/02/2012 03:51, Paul H. Hargrove a écrit :
> The problem I described below is ALSO present in hwloc-1.4
> -Paul
>
> On 1/31/2012 4:57 PM, Paul H. Hargrove wrote:
>> This report is the flip-sid
The bitmap code uses ffs*() to find the first bit set.
Brice
Le 01/02/2012 11:58, Jeff Squyres a écrit :
> Paul -- any idea what library that symbol actually lives in?
>
> FWIW, I can't find that symbol -- or anything like it -- in the hwloc code
> base. Is it being pulled in by some dependent
Good to know -- thanks!
(I was a little worried at first, because hwloc-1.3.1 uses a pretty recent
libtool to build itself! LT 2.4)
On Jan 31, 2012, at 10:45 PM, Paul H. Hargrove wrote:
> Upon further examination, I've discovered that this is HARMLESS noise.
> The "|| { rm && ln -s }" part DOE
Paul -- any idea what library that symbol actually lives in?
FWIW, I can't find that symbol -- or anything like it -- in the hwloc code
base. Is it being pulled in by some dependent library?
On Jan 31, 2012, at 7:57 PM, Paul H. Hargrove wrote:
> This report is the flip-side of the problem w/
Le 01/02/2012 03:52, Paul H. Hargrove a écrit :
>> ...c343//hwloc-1.3.1/doc/doxygen-doc/man/man3/HWLOC_OBJ_PU.3
>> /export/home
>> /phargrov/O
>> '/export/home/phargrov/OMPI/hwloc-1.3.1-solaris10-x86-gcc343/INST/share/man/man3'
>> /export/home/phargrov/OMPI/hwloc-1.3.1-solaris10-x86-gcc343//hwloc-1
I fixed this one, thanks.
Brice
Le 01/02/2012 03:50, Paul H. Hargrove a écrit :
> The problem I described below is ALSO present in hwloc-1.4
> -Paul
>
> On 1/31/2012 5:19 PM, Paul H. Hargrove wrote:
>> On my old Red Hat 8 box, I see the following failure from "make
>> install" of hwloc-1.3.1:
>>
Le 01/02/2012 06:49, Paul H. Hargrove a écrit :
> The failure is only w/ {C,CXX}FLAGS=-mabi=64.
> With the "32" or "n32" ABI's there is no problem.
> That is why it was not seen on the 32-bit system.
>
> I have no other gcc for that system at the moment.
> So, I can't determine if it is a compiler
The failure is only w/ {C,CXX}FLAGS=-mabi=64.
With the "32" or "n32" ABI's there is no problem.
That is why it was not seen on the 32-bit system.
I have no other gcc for that system at the moment.
So, I can't determine if it is a compiler bug.
It may also be a matter of which libs exist in 32-vs-
36 matches
Mail list logo
