I
=dWPv
-END PGP SIGNATURE-
___
hwloc-devel mailing list
hwloc-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research De
showing me the logical->physical layout of
screens on a multi-headed X server, right?
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
URE-
___
hwloc-devel mailing list
hwloc-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel:
On 2/20/2012 1:26 PM, Brice Goglin wrote:
Le 08/02/2012 22:33, Paul H. Hargrove a écrit :
Tests on the virtual node I have access to where that problem report
originated is still not quite right.
There is now a different assertion failing than I had seen before:
lt-linux-libnuma:
/users/phh1
__hwloc_inline const char *
hwloc_obj_get_info_by_name(hwloc_obj_t obj, const char *name)
{
...
}
does it work that way?
Samuel
Yes. That worked!
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
: 1506-277 (S)
Syntax error: possible missing ';' or ','?
make[1]: *** [topology.lo] Error 1
So, we are safer sticking with the current form and ignoring the warning.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research
tribute_pure
+static __hwloc_inline __hwloc_attribute_pure const char *
hwloc_obj_get_info_by_name(hwloc_obj_t obj, const char *name)
{
unsigned i;
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-23
see only 2 problems at this point:
+ known libnuma issues on a "wierd" virtual node - NOT expected to fix
in 1.3.x
+ "make check" failure w/ icc-8.0 on x86/Linux - BUT icc-9.0 and gcc are
both fine on the same node (so probably a compiler bug).
So, I agree this looks &q
ompi_cv_cc_fvisibility="yes"
fi
else
ompi_cv_cc_fvisibility="yes"
fi],
[ompi_cv_cc_fvisibility="no"])
])
-Paul
--
Paul H. Hargrove
sure I was testing the right version.)
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
in this respect.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
On 2/10/2012 9:27 AM, Paul H. Hargrove wrote:
I have versions 8.1.032, 9.0.024 and 9.1.042 of the Intel compilers on
a Linux/x86 (32-bit) host.
All three can configure and build hwloc-1.3.2rc1, but all are failing
"make check" in the same way.
What I see is ton(ne)s of linke
On 2/9/2012 2:26 PM, Paul H. Hargrove wrote:
We then test if *either* set the variable.
Sort of a double-negative.
One of De Morgan's Laws:
NOT (A AND B) = (NOT A) OR (NOT B)
Applied to give:
NOT (TEST1_FAIL AND TEST2_FAIL)
= (NOT TEST1_FAIL) OR (NOT TEST2_FAIL
AC_MSG_CHECKING([for old prototype of sched_setaffinity])
@@ -403,6 +411,9 @@
#define _GNU_SOURCE
#include
]])
+# Restore the CFLAGS if we modified them above
+AS_IF([test "$hwloc_c_vendor" = "ibm"],
+ [CFLAGS=HWLOC_CFLAGS])
AC_MSG_CHECKING([for
On 2/9/2012 4:48 AM, Jeff Squyres wrote:
On Feb 8, 2012, at 6:02 PM, Paul H. Hargrove wrote:
The file config/hwloc_check_vendor.m4 that is present in trunk, is ABSENT in
the 1.3.2rc1 tarball.
There is, correspondingly, no call to _HWLOC_C_COMPILER_VENDOR in hwloc.m4.
Correct -- we hadn't
On 2/8/2012 4:41 PM, Paul H. Hargrove wrote:
I do agree w/ Samuel that the BEST solution is to apply "-qhalt=e"
ONLY to the test(s) where one expects the compiler to through errors
(rather than warnings) for function calls with argument counts which
don't match the
On 2/8/2012 4:43 PM, Samuel Thibault wrote:
Paul H. Hargrove, le Thu 09 Feb 2012 01:41:47 +0100, a écrit :
On 2/8/2012 4:31 PM, Samuel Thibault wrote:
Paul H. Hargrove, le Thu 09 Feb 2012 01:28:53 +0100, a écrit :
Option #4:
CFLAGS='-qhalt=e -qsuppress=1506-077'
Appears to work for me
On 2/8/2012 4:31 PM, Samuel Thibault wrote:
Paul H. Hargrove, le Thu 09 Feb 2012 01:28:53 +0100, a écrit :
Option #4:
CFLAGS='-qhalt=e -qsuppress=1506-077'
Appears to work for me for xlc-8.0 and xlc-9.0.
That still looks dangerous to me: we don't know whatever warning
might be added
On 2/8/2012 8:58 AM, Jeff Squyres wrote:
Please test!
http://www.open-mpi.org/software/hwloc/v1.3/
I have access to BG/L, BG/P, Cray-XT and Cray-XE systems.
Are there any tests I could/should consider running on those?
-Paul
--
Paul H. Hargrove phhargr
ine visibility and other
things going quite wrong with various compilers.
The file config/hwloc_check_vendor.m4 that is present in trunk, is
ABSENT in the 1.3.2rc1 tarball.
There is, correspondingly, no call to _HWLOC_C_COMPILER_VENDOR in hwloc.m4.
Am I correct here, or have I missed something?
-Paul
--
On 2/8/2012 1:10 PM, Paul H. Hargrove wrote:
On 2/8/2012 8:58 AM, Jeff Squyres wrote:
* Detect when a compiler such as xlc may not report compile errors
properly, causing some configure checks to be wrong. Thanks to
Paul H. Hargrove for reporting the problem and providing a patch
SS.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
forward or backward progress.
Maybe the sanity check is just different between 1.3 and trunk?
So, I figured I had better report it.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
On 2/8/2012 8:58 AM, Jeff Squyres wrote:
* Detect when a compiler such as xlc may not report compile errors
properly, causing some configure checks to be wrong. Thanks to
Paul H. Hargrove for reporting the problem and providing a patch.
Looks like I botched this one!
I have added two
about xlc on MacOS 10.3?
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
On 2/3/2012 11:52 AM, Paul H. Hargrove wrote:
Building from the trunk w/ CFLAGS="-march=5kc -mabi=64" I no longer
see any test failures.
I can report success with -mabi=32 and -mabi=n32 as well.
I've finally been able to get Debian squeeze booted under
qemu-system-mips64.
I am d
On 2/3/2012 10:01 AM, Samuel Thibault wrote:
Paul H. Hargrove, le Wed 01 Feb 2012 20:18:59 +0100, a écrit :
So if qemu's emulation were at fault, then one would expect more wide-spread
problems and a generally unstable system.
While -mabi=64 is not the default in user-space, it IS the way
On 2/3/2012 10:28 AM, Paul H. Hargrove wrote:
It occurs to me now that xlc MIGHT have an option to make only the
specific (E) become fatal.
I will look and report back.
Nope.
I could find -qsuppress= to suppress given messages, but no way
to elevate given ones to fatal.
-Paul
--
Paul H
of xlc when given no arguments is an entire manpage, not
just the version info!
It occurs to me now that xlc MIGHT have an option to make only the
specific (E) become fatal.
I will look and report back.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologie
Samuel Thibault wrote:
Paul H. Hargrove, le Wed 01 Feb 2012 06:50:12 +0100, 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 tested on a debian po
Samuel Thibault wrote:
Paul H. Hargrove, le Wed 01 Feb 2012 05:58:05 +0100, a écrit :
The older distro w/ the 64-bit kernel is failing:
$ cat /etc/debian_version ; uname -a
5.0.9
Linux qemu-hargrove-mips 2.6.24-etchnhalf.1-5kc-malta #1 Thu Oct 16
01:21:56 BST 2008 mips64 GNU/Linux
uld that work?
thanks
Brice
Le 02/02/2012 02:28, Paul H. Hargrove a écrit :
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 preproces
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
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 f
between types "unsigned long" and "void*" is not allowed.
"conftest.c", line 89.19: 1506-098 (E) Missing argument(s).
configure:9064: $? = 0
configure:9068: result: yes
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.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
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
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
libs exist in 32-vs-64 bit versions on
this system.
-Paul
On 1/31/2012 8:57 PM, Paul H. Hargrove wrote:
I have 2 QEMU-emulated Linux/MIPS systems.
On one hwloc-1.3.1 and 1.4 are working fine.
On the other I see strange "make check" failures.
Unfortunately they differ in both di
moment my suspicion falls on the compiler, as I can't see how a
failure of 256ia64-64n2s2c.output could be h/w dependent.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrenc
t, because the `ln' binary might depend on
# the symlink we replace! Solaris /bin/ln does not
understand -f,
# so we also need to try rm && ln -s.
Sorry for this report, which turned out NOT to be an actual problem.
-Paul
On 1/31/2012 6:53 PM, Paul H. Hargrove wrote
The problem I described below is ALSO present in hwloc-1.4
-Paul
On 1/31/2012 5:37 PM, Paul H. Hargrove wrote:
Testing hwloc-1.3.1 on a Pentium III running Solaris-10, I am getting
the following sort failure from "make install":
/export/home/phargrov/OMPI/hwloc-1.3.1-solaris10-
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-side of the problem w/ Solaris Studio
compilers on x86-64.
With Solaris-10 on SPARC, I find I *can* build hwloc-1.3.1 w/ SS12.x,
but instead am failing w/ gcc
The problem I described below is ALSO present in hwloc-1.4
-Paul
On 1/31/2012 4:48 PM, Paul H. Hargrove wrote:
When Jeff Squyres indicated that ompi-1.5.5 will use hwloc-1.3.x, I
started putting hwloc-1.3.1 through my testing gauntlet.
I am sorry I didn't find this in the 1.3.1rc2, but when
mp;& ln -s libhwloc.so.4.1.4 libhwloc.so.4; }; })
Usage: ln [-f] [-s] f1
ln [-f] [-s] f1 f2
ln [-f] [-s] f1 ... fn d1
This is because "ln -s -f" is being run by libtool while "ln" on this
platform is happy only with "ln -f -s".
This sensitivi
phargrov/O does not exist.
I think it would be safe to venture a guess from the truncated name in
the "does not exist", that this command has exceeded the maximum command
line length. The subsequent commands to install manpages suffer the
same sort of problem.
-Paul
pecific to GNU sed-4.x
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
+;;
+ *)
+AC_MSG_RESULT([unknown])
+;;
esac
AC_CHECK_SIZEOF([unsigned long])
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486
.,
Fedora 8).
* Open MPI trunk (which will eventually become the v1.7 series): it's ok to be
a bit more forward-looking here. I'm actually pretty convinced that this one
should be upgraded to hwloc 1.3.1 (or whatever the latest set of fixes is) in
the near future.
Thoughts?
--
Paul H. Hargrove
is "vital".
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
lstopo show PCI devices on your machine even when you
have these warnings?
Yes, the PCI device info looks complete even with the warnings.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495
On 12/14/2011 12:03 PM, Brice Goglin wrote:
Le 14/12/2011 20:45, Paul H. Hargrove a écrit :
I can run "lspci -vv" to get plenty of correct information and no such
messages.
What about lspci -vvxxx ? These options makes the pci lib read 256
instead of 64 bytes of config spa
now what else might be needed to address this problem (or at
least determine if it is even a hwloc problem or not).
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
On 12/14/2011 12:53 AM, Samuel Thibault wrote:
Paul H. Hargrove, le Wed 14 Dec 2011 09:50:23 +0100, a écrit :
It appears that something has passed bogus arguments to hwloc-calc.
Adding "set -x" in test-hwloc-calc.sh.in I can find the failure is from:
./hwloc-calc --if synthet
lc --if synthetic --input "node:4 core:4 pu:4" pu:22-47
--largest --sep ""
Which I can confirm fails when run by hand on this platform, but works
fine elsewhere.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Researc
54 matches
Mail list logo
