Re: [hwloc-devel] hwloc-1.4 "gmake check" failure on Solaris-10/SPARC/gccfss [PATCH]

Paul H. Hargrove, le Thu 02 Feb 2012 02:29:08 +0100, a écrit : > + The configure-time logic is NOT trying to determine the version number, as > I don't have a way (yet?) to pinpoint which version(s) work correctly, and > the Oracle Forums thread on the subject doesn't say. So, it is >

Re: [hwloc-devel] hwloc-1.3.1 and 1.4 failures on MIPS64/qemu

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 the linux > kernel is built and thus should be

Re: [hwloc-devel] hwloc-1.3.1 and 1.4 failures on MIPS64/qemu

Paul H. Hargrove, le Fri 03 Feb 2012 20:53:28 +0100, a écrit : > I do see, from hwloc-hello: > *** The number of sockets is unknown > *** Logical processor 0 has 0 caches totaling 0KB > IFF there is reason to expect better from this system, I'd be happy to work > w/ somebody on fixing that. I

Re: [hwloc-devel] 1.3.2rc1 has escaped

Jeff Squyres, le Wed 08 Feb 2012 17:59:04 +0100, a écrit : > Please test! > > http://www.open-mpi.org/software/hwloc/v1.3/ Could somebody test it on AIX, and with xlc? Thanks, Samuel

Re: [hwloc-devel] 1.3.2rc1 has escaped

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

Re: [hwloc-devel] 1.3.2rc1 has escaped

Samuel Thibault, le Thu 09 Feb 2012 01:43:56 +0100, a écrit : > 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: > &g

Re: [hwloc-devel] excessive warnings from xlc w/ hwloc-trunk

Paul H. Hargrove, le Sat 18 Feb 2012 00:58:27 +0100, a écrit : > I am not sure of the risk/reward on applying this change, however. > Gcc seems to be happy enough either way as far as I could tell. > -static __hwloc_inline const char * __hwloc_attribute_pure > +static __hwloc_inline

Re: [hwloc-devel] excessive warnings from xlc w/ hwloc-trunk

Paul H. Hargrove, le Sun 19 Feb 2012 21:37:50 +0100, a écrit : > On 2/19/2012 10:54 AM, Samuel Thibault wrote: > [snip] > >Does it still complain if using the following? > >>static __hwloc_inline const char * > >> hwloc_obj_get_info_by_name(hwl

Re: [hwloc-devel] hwloc_alloc_membind

Karl Napf, le Fri 24 Feb 2012 13:04:58 +0100, a écrit : > What surprises me is that the result of the call to > hwloc_fix_membind_cpuset in line 534 of bind.c is negated, even though > hwloc_fix_membind_cpuset returns 0 on success. Might this be a bug? Oops, indeed. > 2. In another use case I

Re: [hwloc-devel] hwloc_alloc_membind

Karl Napf, le Fri 24 Feb 2012 14:45:26 +0100, a écrit : > Thanks a lot, Samuel. BTW the documentation says that > hwloc_alloc_membind and hwloc_alloc_membind_nodeset return -1 on > error, but this should be NULL. Indeed! Thanks, Samuel

Re: [hwloc-devel] merging instruction cache branch

Brice Goglin, le Tue 13 Mar 2012 14:39:50 +0100, a écrit : > There's a topology flag ("ICACHES") to enable Instruction cache > detection, and a lstopo options (--icaches). Mmm, we enable PCI devices in lstopo by default already, I would say that we could enable icache by default too. Not a strong

[hwloc-devel] Checking that we use portability macros Was: [hwloc-svn] svn:hwloc r4382

sthib...@osl.iu.edu, le Tue 13 Mar 2012 17:46:36 +0100, a écrit : > Always hwloc_strncasecmp, not strncasecmp We should probably add checks against such things, we have the same problem with __inline, that people tend to use instead of our portability hwloc_inline. I'm not sure how that fits best

Re: [hwloc-devel] Hydra job runtime:hwloc-trunk:build_fedora2_i386 on x86_64-linux, build 36199: Failed

Brice Goglin, le Thu 15 Mar 2012 17:36:29 +0100, a écrit : > Looks like g++ doesn't like __hwloc_attribute_unused in hwloc/helper.h I wonder what Hydra uses for g++. I have tested various versions (from 4.1 to 4.7), without problems. Samuel

Re: [hwloc-devel] Hydra job runtime:hwloc-trunk:build_fedora2_i386 on x86_64-linux, build 36199: Failed

Brice Goglin, le Fri 16 Mar 2012 07:48:52 +0100, a écrit : > Le 16/03/2012 02:44, Samuel Thibault a écrit : > > Brice Goglin, le Thu 15 Mar 2012 17:36:29 +0100, a écrit : > >> Looks like g++ doesn't like __hwloc_attribute_unused in hwloc/helper.h > > I wonder what Hydra use

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r4409

Jeffrey Squyres, le Tue 20 Mar 2012 15:51:54 +0100, a écrit : > What do you think of this patch? It separates out the individual version > checking to make the #define logic a little easier to read. Interesting indeed, I vote for it. Samuel

Re: [hwloc-devel] BGQ empty topology with MPI

Daniel Ibanez, le Wed 21 Mar 2012 03:37:25 +0100, a écrit : > Please let me know if theres a hint of what could be causing it, > where to post, and what info to provide. This is already the proper list. Please attach the output of lstopo after having given the --enable-debug option to

Re: [hwloc-devel] BGQ empty topology with MPI

Brice Goglin, le Thu 22 Mar 2012 10:58:46 +0100, a écrit : > I don't see anything bad in your outputs. > So there's something strange going on when MPI is added. Which MPI are using? > Is this a derivative of MPICH that embeds hwloc? (MPICH >= 1.2.1 if I remember > correctly) There might be

Re: [hwloc-devel] BGQ empty topology with MPI

Daniel Ibanez, le Thu 22 Mar 2012 23:07:01 +0100, a écrit : > I suspected this might be the reason, so I called "nm" > with the static versions of the libraries their compiler wrappers > link against and I could not find the term "hwloc" in the output. > Is this a valid test? Ah, right, embedded

Re: [hwloc-devel] Fwd: BGQ empty topology with MPI

Daniel Ibanez, le Wed 28 Mar 2012 20:23:18 +0200, a écrit : > The machine is back in working order. > I tried this patch and it works great: I get cpus and my whole program runs as > expected. Maybe it could be a safe fallback that we should keep anyway, even if we work out the issue with sysfs.

Re: [hwloc-devel] interoperability with X displays

Samuel Thibault, le Thu 29 Mar 2012 17:56:28 +0200, a écrit : > Brice Goglin, le Thu 29 Mar 2012 16:09:00 +0200, a écrit : > > The lib is unfortunately only built as a static lib in at least debian > > and ubuntu (without -fPIC), which is annoying. > > That might be fixa

Re: [hwloc-devel] interoperability with X displays

Marwan Abd Ellah, le Mon 16 Apr 2012 13:53:57 +0200, a écrit : > I have checked the package contents on Debia sid and I haven't seen any > updates >  at  > http://packages.debian.org/sid/amd64/nvidia-settings/filelist > Would you please refer to the place where I can find the libXNVCtrl.so  ?

Re: [hwloc-devel] lstopo-nox strikes back

Jeff Squyres, le Wed 25 Apr 2012 16:55:23 +0200, a écrit : > On Apr 25, 2012, at 10:48 AM, Samuel Thibault wrote: > > >> FWIW: Having lstopo plugins for output would obviate the need for having > >> two executable names. > > > > Well, it seems overkill to me

Re: [hwloc-devel] lstopo-nox strikes back

Brice Goglin, le Wed 25 Apr 2012 16:58:16 +0200, a écrit : > On 25/04/2012 16:55, Jeff Squyres wrote: > >On Apr 25, 2012, at 10:48 AM, Samuel Thibault wrote: > > > >>>FWIW: Having lstopo plugins for output would obviate the need for having > >>>two execut

Re: [hwloc-devel] lstopo-nox strikes back

Jeff Squyres, le Wed 25 Apr 2012 17:03:01 +0200, a écrit : > On Apr 25, 2012, at 10:58 AM, Samuel Thibault wrote: > > > It already adapts itself, here. The issue is that the user has to > > install an X version to get potential for X support. Which brings X. > > If

Re: [hwloc-devel] lstopo-nox strikes back

Jeff Squyres, le Wed 25 Apr 2012 17:11:28 +0200, a écrit : > Yes: the lstopo user gets whatever the sysadmin chose to install. > No: the system is not flexible for binary distributions > > Meaning: I see 2 ways to have binary packages that have X/cairo support and > don't have X/cairo support: >

Re: [hwloc-devel] lstopo-nox strikes back

Brice Goglin, le Fri 27 Apr 2012 19:09:47 +0200, a écrit : > Le 25/04/2012 15:42, Jiri Hladky a écrit : > > I would vote to make lstopo ASCII only and introduce new GUI binary > > "lstopo-gui" in the version 1.5 > > I'll commit that during the weekend unless somebody comes with a better >

Re: [hwloc-devel] [PATCH] Use plain "inline" in C++

Jeff Squyres, le Wed 09 May 2012 22:59:43 +0200, a écrit : > Samuel -- does this look right to you? If so, I can apply to 1.3, 1.4, and > trunk. > > +/* Note that if we're compiling C++, then just use the "inline" > + keyword, since it's part of C++ */ > +#if defined(c_plusplus) ||

Re: [hwloc-devel] [PATCH] Use plain "inline" in C++

Jeff Squyres, le Wed 09 May 2012 23:41:20 +0200, a écrit : > On May 9, 2012, at 5:32 PM, Samuel Thibault wrote: > > >> +/* Note that if we're compiling C++, then just use the "inline" > >> + keyword, since it's part of C++ */ > >> +#if defined(c_pluspl

Re: [hwloc-devel] lstopo-gui

Jeff Squyres, le Fri 25 May 2012 12:34:38 +0200, a écrit : > >From my checkout, it looks like lstopo-no-graphics supports: > > console, txt, fig, xml, synthetic > > How did fig get in there, btw? Doesn't that add dependencies? (or did that > get coded up manually / with no library

Re: [hwloc-devel] HWLOC_NBMAXCPUS

TERRY DONTJE, le Thu 21 Jun 2012 15:47:22 +0200, a écrit : > I see a couple places where HWLOC_NBMAXCPUS is defined with a comment of > "FIXME: drop".  This static size just bit me on a machine that has 1440 CPUs.  > I can bump up the define in my clone but I was wondering if this fixed size >

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r4554 - trunk/utils

Brice Goglin, le Fri 29 Jun 2012 22:10:30 +0200, a écrit : > --pid doesn't care about binding, it just changes things like cgroups Uh? It's in there since a long time: lstopo-draw.c pu_draw(): else if (pid == 0) hwloc_get_cpubind(topology, bind, 0); if (bind &&

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r4554 - trunk/utils

Brice Goglin, le Fri 29 Jun 2012 22:29:20 +0200, a écrit : > Arg, I was using the console output (hwloc-nox). Ah, you should be able to use -.txt then, it colorizes there too. Samuel

Re: [hwloc-devel] XML string filtering

Brice Goglin, le Fri 06 Jul 2012 14:50:46 +0200, a écrit : > I could just use isprint() to check every character > before export and only keep those between 32 and 127. Why not just taking 32-126? I don't see what isprint will bring. > But what about \n, > \t, \r, \f which are before ? Do we

Re: [hwloc-devel] hwloc_bitmap_or

Pavan Balaji, le Sat 21 Jul 2012 04:40:22 +0200, a écrit : > In hwloc_bitmap_or(), is the resultant bitmap allowed to be the same as one > of the input bitmaps? It seems to work correctly in practice, but the API > doesn't seem to explicitly guarantee it. We actually use it a lot in the core.

Re: [hwloc-devel] backends and plugins

Brice Goglin, le Wed 22 Aug 2012 07:52:07 +0200, a écrit : > Le 21/08/2012 21:18, Samuel Thibault a écrit : > > Brice Goglin, le Tue 21 Aug 2012 18:49:48 +0200, a écrit : > >> 1) We load plugins and list existing components once per topology. We > >> should

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r4815 - branches/components/src

Brice Goglin, le Wed 05 Sep 2012 16:13:31 +0200, a écrit : > The problem I was trying to fix below is that linking hwloc plugins on > Darwin failed because plugins referred to hwloc-core symbols. Nothing on > the libtool command-line said where to find those symbols (I don't > understand why it

Re: [hwloc-devel] -lhwloc in components.

Jeff Squyres, le Wed 05 Sep 2012 17:06:00 +0200, a écrit : > On Sep 5, 2012, at 10:21 AM, Samuel Thibault wrote: > > > So ltdl does not help for that matter? > > No. It's not really an ltdl issue. ltdl is just a portable wrapper around > OS-specific dlopen-like mechan

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r4815 - branches/components/src

Jeff Squyres, le Thu 06 Sep 2012 15:46:29 +0200, a écrit : > On Sep 6, 2012, at 7:46 AM, Jeff Squyres wrote: > > (sorry; I forgot to ping Shiqing yesterday -- I just did so now to get a > > confirmation of what you found) > > > Shiqing confirms that DSOs are disabled by default on Windows.

Re: [hwloc-devel] merging plugins?

Hello, Brice Goglin, le Mon 24 Sep 2012 22:04:14 +0200, a écrit : > 1) A rework of the backend infrastructure to make the core much more > readable (basically all changes in *.[ch] files). That looks nicer indeed. > 2) Plugin support One thing that doesn't seem implemented yet is to choose

Re: [hwloc-devel] merging plugins?

Brice Goglin, le Tue 25 Sep 2012 07:41:48 +0200, a écrit : > * Your HWLOC_PLUGINS variable is not about loading plugins, it's about > enabling core components. It could also be to use another PCI detection plugin that libpci. Samuel

Re: [hwloc-devel] merging plugins?

Brice Goglin, le Tue 25 Sep 2012 10:34:29 +0200, a écrit : > I am also going to add a hwloc_ prefix to plugin filenames because we > obviously can't create a libpci.so (libtool even warns about this). And it makes things clearer, I believe. > XML backends could be hwlocxml_ (not hwloc_xml_) to

Re: [hwloc-devel] merging plugins?

Brice Goglin, le Tue 25 Sep 2012 11:08:04 +0200, a écrit : > >> We have the "core_xml" component (generic xml support) and "xml_libxml" > >> + "xml_nolibxml" backends behind that. I am fine with removing the > >> "core_" prefix, but I wonder if we should keep the "xml_" prefix for the > >> latter.

Re: [hwloc-devel] [hwloc-users] hwloc 1.5, freebsd and linux output on the same hardware

Sebastian Kuzminsky wrote: > Maybe lstopo should expand its cpuset to be fully inclusive at startup? I'll > be happy to test patches if you want. Brice Goglin, le Thu 11 Oct 2012 18:13:53 +0200, a écrit : > Is the cpuset-modification a root-only operation on FreeBSD? If so lstopo > wouldn't be

Re: [hwloc-devel] plugins update

Brice Goglin, le Thu 08 Nov 2012 13:48:39 +0100, a écrit : > Did anybody look at leastc at the documentation links below? Yep, it looks nice! Samuel

Re: [hwloc-devel] v1.7

Brice Goglin, le Mon 31 Dec 2012 10:05:41 +0100, a écrit : > - They add OS devices such as opencl0p0, I see that platform 0 device 3 would be called opencl3p0. I find it counterintuitive, and would have rather called it opencl0d3, along the line of sda3, eth0:3, socket:2.core:0, etc. What do

Re: [hwloc-devel] v1.7

Hello, Brice Goglin, le Mon 31 Dec 2012 10:05:41 +0100, a écrit : > + The HWLOC_COMPONENTS may now start with '^' to only define a list of > components to exclude. I'm finding it not intuitive and not generic enough, I'm wondering how that didn't affect Open-MPI, which as IUI uses this

Re: [hwloc-devel] v1.7

Brice Goglin, le Mon 07 Jan 2013 17:33:47 +0100, a écrit : > Ideally, we could even have a OS device for each OpenCL platform, each > containing OS devices for devices of the platform. But I'd rather keep a > single level to match other OS devices. In most cases the platform object wouldn't bring

Re: [hwloc-devel] v1.7

Jeff Squyres (jsquyres), le Mon 07 Jan 2013 19:19:15 +0100, a écrit : > On Jan 7, 2013, at 12:59 PM, Samuel Thibault <samuel.thiba...@inria.fr> > > Because I may not know *everything* that I want. Who knows what > > proprietary plugin I need to use to discover CPUs, while I k

Re: [hwloc-devel] v1.7

Brice Goglin, le Mon 07 Jan 2013 19:11:02 +0100, a écrit : > BTW, if we change the hwloc syntax, we may want to not use ^ to avoid > confusion with OMPI. ~ and ! could work but some shells may not like them? How about '-'? I doubt anybody would want a plugin name starting with it. Samuel

Re: [hwloc-devel] v1.7

Jeff Squyres (jsquyres), le Mon 07 Jan 2013 20:01:44 +0100, a écrit : > So if you don't know the list of available components, is it not possible to > specify *only* foo and bar should be used? foo,bar,stop will do it. Samuel

Re: [hwloc-devel] libpci: GPL

Jeff Squyres (jsquyres), le Tue 05 Feb 2013 22:52:01 +0100, a écrit : > The complaint to me was that hwloc needs to be clearer about this in its > documentation. > > Does this sound right? It makes sense that we warn about this, yes, so people know they might want to pass --disable-pci. Samuel

Re: [hwloc-devel] [mpich-core] libpci: GPL

Pavan Balaji, le Wed 06 Feb 2013 00:07:10 +0100, a écrit : > > On 02/05/2013 04:52 PM US Central Time, Pavan Balaji wrote: > > If libpci was disabled by default, would hwloc still come under the same > > GPL issue? > > I realized that wasn't very clear. Let me rephrase -- if libpci was >

Re: [hwloc-devel] libpci: GPL

Pavan Balaji, le Tue 05 Feb 2013 23:53:54 +0100, a écrit : > I checked libnuma, which seems to be LGPL (phew!), but didn't look at > the remaining libraries hwloc uses. The base of hwloc needs libm/libc (LGPL), plugin support needs libltdl (LGPL) and libdl (LGPL). Samuel

Re: [hwloc-devel] libpci: GPL

Jeff Squyres (jsquyres), le Tue 05 Feb 2013 22:52:01 +0100, a écrit : > It was just pointed out to me that libpci is licensed under the GPL (not the > LGPL). I'm told that we could use libpciaccess instead, which is BSD. Samuel

Re: [hwloc-devel] libpci: GPL

Jeff Squyres (jsquyres), le Wed 06 Feb 2013 01:41:21 +0100, a écrit : > On Feb 5, 2013, at 3:50 PM, Samuel Thibault <samuel.thiba...@inria.fr> wrote: > > > Jeff Squyres (jsquyres), le Tue 05 Feb 2013 22:52:01 +0100, a écrit : > >> It was just pointed out to me th

Re: [hwloc-devel] libpci: GPL

Samuel Thibault, le Wed 06 Feb 2013 01:55:18 +0100, a écrit : > Jeff Squyres (jsquyres), le Wed 06 Feb 2013 01:41:21 +0100, a écrit : > > On Feb 5, 2013, at 3:50 PM, Samuel Thibault <samuel.thiba...@inria.fr> > > wrote: > > > > > Jeff Squyres (jsquyres

Re: [hwloc-devel] libpci: GPL

Brice Goglin, le Wed 06 Feb 2013 07:11:03 +0100, a écrit : > Any idea why it doesn't find your nvidia card? Well, actually it does, but vendor id & co are all 0x > By the way, the contamination should be limited to the libpci plugin > when plugins are enabled. Right. Samuel

Re: [hwloc-devel] libpci: GPL

Brice Goglin, le Wed 06 Feb 2013 16:03:21 +0100, a écrit : > I am not sure yet if we should add a > --disable-gpl or --enable-gpl, Jeff Squyres (jsquyres), le Wed 06 Feb 2013 16:11:55 +0100, a écrit : > - if found, and if --enable-gpl-taint was specified, use it. STOP. Such kind of options are

Re: [hwloc-devel] libpci: GPL

Jeff Squyres (jsquyres), le Wed 06 Feb 2013 17:33:03 +0100, a écrit : > On Feb 6, 2013, at 8:21 AM, Samuel Thibault <samuel.thiba...@inria.fr> wrote: > > >> - if found, and if --enable-gpl-taint was specified, use it. STOP. > > > > Such kind of options are quest

Re: [hwloc-devel] libpci: GPL

Brice Goglin, le Wed 06 Feb 2013 07:11:03 +0100, a écrit : > Any idea why it doesn't find your nvidia card? Actually it is due to my use of bumblebee, which puts the graphic card into sleep when not running CUDA. Running lstopo through optirun brings the card back. It actually makes sense, I

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r5299 - in branches/bgq: config include/private src

Brice Goglin, le Fri 08 Feb 2013 13:23:33 +0100, a écrit : > Le 08/02/2013 12:52, Samuel Thibault a écrit : > > svn-commit-mai...@open-mpi.org, le Fri 08 Feb 2013 12:02:18 +0100, a écrit : > >> Everything is hardwired in the backend, all nodes are the same. > > Would it b

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r5299 - in branches/bgq: config include/private src

Brice Goglin, le Fri 08 Feb 2013 13:34:01 +0100, a écrit : > Le 08/02/2013 13:26, Samuel Thibault a écrit : > > Brice Goglin, le Fri 08 Feb 2013 13:23:33 +0100, a écrit : > >> Le 08/02/2013 12:52, Samuel Thibault a écrit : > >>> svn-commit-mai...@open-mpi.org, le

Re: [hwloc-devel] libpci: GPL

Christopher Samuel, le Tue 19 Feb 2013 05:30:40 +0100, a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/02/13 10:29, Samuel Thibault wrote: > > > Right. If hwloc was strictly requiring a GPL library to be able > > to run, providing it under BSD wo

Re: [hwloc-devel] v1.7

Hello, I'm realizing that this was actually not settled on. I've just fixed my previous text with the current syntax Samuel Thibault, le Mon 07 Jan 2013 15:05:55 +0100, a écrit : > Brice Goglin, le Mon 31 Dec 2012 10:05:41 +0100, a écrit : > > + The HWLOC_COMPONENTS may

Re: [hwloc-devel] Hardware locality (hwloc) v1.7rc1 released

Brice Goglin, le Thu 04 Apr 2013 18:02:33 +0200, a écrit : > I haven't seen any problem on various Linux distribs, several BSDs, some > Solaris, and AIX 6.1. Same for me (including hp-ux). Samuel

Re: [hwloc-devel] Hardware locality (hwloc) v1.7rc1 released

Samuel Thibault, le Fri 05 Apr 2013 09:11:31 +0200, a écrit : > Brice Goglin, le Thu 04 Apr 2013 18:02:33 +0200, a écrit : > > I haven't seen any problem on various Linux distribs, several BSDs, some > > Solaris, and AIX 6.1. > > Same for me (including hp-ux). Ah, mic devi

Re: [hwloc-devel] Hardware locality (hwloc) v1.7rc1 released

Samuel Thibault, le Fri 05 Apr 2013 14:08:16 +0200, a écrit : > Samuel Thibault, le Fri 05 Apr 2013 09:11:31 +0200, a écrit : > > Brice Goglin, le Thu 04 Apr 2013 18:02:33 +0200, a écrit : > > > I haven't seen any problem on various Linux distribs, several BSDs, some > >

Re: [hwloc-devel] Compiling hwloc 1.7 with NV support

Hello, Jiri Hladky, le Sat 20 Apr 2013 00:57:18 +0200, a écrit : > topology-gl.c: In function 'hwloc_gl_query_devices': > topology-gl.c:91:41: error: 'NV_CTRL_PCI_DOMAIN' undeclared (first use in this > > Indeed, there is no NV_CTRL_PCI_DOMAIN MACRO defined in NVCtrl header files: > > grep

Re: [hwloc-devel] RPATH issues when building in Fedora 18

Paul Hargrove, le Wed 24 Apr 2013 08:06:03 +0200, a écrit : > In my testing on Fedora 17, the patch below applied to hwloc-1.7 produces an > accurate sys_lib_dlsearch_path_spec > > --- config/libtool.m4~ 2013-04-07 16:29:21.0 -0700 > +++ config/libtool.m4  2013-04-23 22:43:52.88200

Re: [hwloc-devel] hwloc-1.7 Warnings on FreeBSD

Pavan Balaji, le Fri 03 May 2013 06:45:10 +0200, a écrit : > -Wbad-function-cast'. > > lstopo-draw.c:437: warning: cast from function call of type 'double' to > non-matching type 'unsigned int' I'm not sure to understand what one is supposed to do here. double->float->unsigned is less precise

Re: [hwloc-devel] hwloc embedding vs libltdl

Jeff Squyres (jsquyres), le Wed 08 May 2013 02:21:02 +0200, a écrit : > On May 7, 2013, at 6:25 PM, Brice Goglin wrote: > > > I don't have anything against this. What was the reason for not using > > the default/system libltdl in OMPI? libtool was buggy when you started >

Re: [hwloc-devel] plugins inside plugin broken, as expected

Brice Goglin, le Mon 03 Jun 2013 10:46:49 +0200, a écrit : > hwloc/bitmap.h is the biggest problem, plugins should be allowed to use > all of them but there are many of them. Splitting hwloc-bitmap.so > out of hwloc.so would be an easy way to solve this. The bitmap API is > totally independent

Re: [hwloc-devel] plugins inside plugin broken, as expected

Brice Goglin, le Mon 03 Jun 2013 19:50:26 +0200, a écrit : > Le 03/06/2013 10:52, Samuel Thibault a écrit : > > Brice Goglin, le Mon 03 Jun 2013 10:46:49 +0200, a écrit : > >> hwloc/bitmap.h is the biggest problem, plugins should be allowed to use > >> all of them but

Re: [hwloc-devel] lstopo --top

Hello, Jiri Hladky, le Tue 18 Jun 2013 17:18:15 +0200, a écrit : > I would like to check the possibilities to visualize the results to the output > similar to lstopo --top (see the attachment). I would like to write a simple > utility which will >  * parse the above file >  * foreach timestep

Re: [hwloc-devel] lstopo --top

Jiri Hladky, le Thu 20 Jun 2013 22:08:03 +0200, a écrit : > lstopo has obviously some logic how to sort the data inserted > by hwloc_topology_insert_misc_object_by_cpuset. Could be data displayed in the > same order as inserted? hwloc_topology_insert_misc_object_by_parent probably does that, you

Re: [hwloc-devel] upcoming cleaning of headers and doc sections

Brice Goglin, le Thu 18 Jul 2013 14:10:28 +0200, a écrit : > * only put the prototypes in hwloc.h and keep the inline code somewhere else > * if some sections are obviously less important, keep these out of > hwloc.h (just like the ones in hwloc/helper.h currently) I'd say these two. Samuel

Re: [hwloc-devel] hwloc-distrib - please add the option to distribute the jobs in the reverse direction

Brice Goglin, le Thu 29 Aug 2013 09:58:17 +0200, a écrit : > Anyway, reversing the loop just move the core you don't want to the end of the > list. But if you use the entire list, you end up using the exact same cores. He wants that, yes. Samuel

Re: [hwloc-devel] Git testing of hwloc

Jeff Squyres (jsquyres), le Sat 07 Sep 2013 00:04:13 +0200, a écrit : > What are your github IDs? sthibaul Samuel

Re: [hwloc-devel] git / nightly builds

Jeff Squyres (jsquyres), le Fri 27 Sep 2013 15:36:33 +0200, a écrit : > a) The last SVN nightly snapshot on the v1.7 branch was named >hwloc-1.7.3rc1r5779.tar.bz2. > b) The first git nightly snapshot on the v1.7 branch will be named >hwloc-1.7.2-4-g3a6f84c.tar.bz2. > > Note

Re: [hwloc-devel] nightly snapshot tarballs now available

Jeff Squyres (jsquyres), le Thu 03 Oct 2013 12:38:05 +0200, a écrit : > On Oct 2, 2013, at 12:47 PM, Brice Goglin wrote: > > I can do it (assuming the "hwloc-svn-conversion" git tree it uptodate). > > But I need somebody to create the ompi/hwloc-debian repo on github and >

Re: [hwloc-devel] nightly snapshot tarballs now available

Samuel Thibault, le Thu 03 Oct 2013 18:01:25 +0200, a écrit : > I have automatically imported the previous debian uploads. I don't > think we really need to keep the detailed commit, the releases have > brought small diffs enough. And that permits to switch to another layout which

Re: [hwloc-devel] Relationship between Cario and X11

Hello, Jeff Squyres (jsquyres), le Fri 01 Nov 2013 14:59:03 +0100, a écrit : > I notice that we have an explicit dependency between Cairo and X11 in > configure: > > Is there any reason for this? I think if there was any it's now gone. > Indeed, I manually disabled this extra check in

Re: [hwloc-devel] Relationship between Cario and X11

Jeff Squyres (jsquyres), le Fri 01 Nov 2013 15:12:31 +0100, a écrit : > Cool. Does the following patch look ok? If so, I'll commit to master and > v1.7: Err, no, we really need to have HWLOC_HAVE_X11 defined when X11 is available, otherwise we won't get the graphical lstopo. Samuel

Re: [hwloc-devel] Relationship between Cario and X11

Jeff Squyres (jsquyres), le Fri 01 Nov 2013 16:01:41 +0100, a écrit : > It looks like this logic isn't quite correct, anyway -- the X11 checks are > embedded in the Cairo and GL sections. Should they moved out to be > independent of Cairo and GL (and therefore only once, and include the >

Re: [hwloc-devel] Relationship between Cario and X11

Jeff Squyres (jsquyres), le Fri 01 Nov 2013 16:33:41 +0100, a écrit : > There's some funny m4 logic in the CHECK_HEADERS for X11. Let me make sure I > understand the intent: > > - X11/Xlib.h: this file is required for X11 support > - X11/Xutil.h X11/keysym.h: these files are optional for X11

Re: [hwloc-devel] Relationship between Cario and X11

Jeff Squyres (jsquyres), le Fri 01 Nov 2013 18:03:55 +0100, a écrit : > On Nov 1, 2013, at 11:54 AM, Samuel Thibault <samuel.thiba...@inria.fr> wrote: > > > We could avoid Xutil.h and keysym.h by disabling the case KeyPress part, > > but I'd rather not: people will wo

Re: [hwloc-devel] hwloc-1.8 patch

Pavan Balaji, le Fri 06 Dec 2013 00:34:30 +0100, a écrit : > Would you consider the following patch for hwloc-1.8 that we embed in the > mpich version of hwloc? The commit log has the description. Please ignore > the extra white-space piece of the commit. This is now commited in master and

Re: [hwloc-devel] Creating a topology generation method for Xen

Hello, Andrew Cooper, le Thu 26 Dec 2013 22:17:38 +0100, a écrit : > I believe can make a topology-xen.c without too much trouble. It likely > wants to checked before an os-specific hook (Xen dom0's come in at least > Linux, FreeBSD, NetBSD flavours which have mainstream support) > Are there any

Re: [hwloc-devel] Creating a topology generation method for Xen

Samuel Thibault, le Thu 26 Dec 2013 22:43:35 +0100, a écrit : > Andrew Cooper, le Thu 26 Dec 2013 22:17:38 +0100, a écrit : > > I believe can make a topology-xen.c without too much trouble. It likely > > wants to checked before an os-specific hook (Xen dom0's come in at least >

Re: [hwloc-devel] Creating a topology generation method for Xen

Andrew Cooper, le Thu 26 Dec 2013 23:31:36 +0100, a écrit : > On 26/12/2013 21:43, Samuel Thibault wrote: > > Andrew Cooper, le Thu 26 Dec 2013 22:17:38 +0100, a écrit : > >> I believe can make a topology-xen.c without too much trouble. It likely > >> wants to checked

Re: [hwloc-devel] hwloc with Xen system support - v2

Hello, Brice Goglin, le Tue 07 Jan 2014 12:54:45 +0100, a écrit : > I currently have a crazy idea for getting at the cache information. > topology-x86.c has a lot of cpuid knowledge, and I have a proposed new > hypercall which executes cpuid on a specific PU. Would it be possible

Re: [hwloc-devel] hwloc with Xen system support - v2

Brice Goglin, le Wed 29 Jan 2014 16:04:54 +0100, a écrit : > We may want to make inputbuffer and outputbuffer generic enough (void* + > length) so that the model works for other architectures one day? Probably, yes. > Xen will know that they correspond to inputbuffer=one-register and >

Re: [hwloc-devel] hwloc-1.9.1 failure on FreeBSD64

Balaji, Pavan, le Thu 04 Sep 2014 14:39:38 +, a écrit : > /home/autotest/balaji/hwloc/hwloc-1.9.1/include/private/misc.h:360:3: error: > implicit declaration of function 'strncasecmp' > [-Werror=implicit-function-declaration] Uh, that's odd, we explicitly test for

Re: [hwloc-devel] Interesting warning

Hello, Ralph Castain, le Wed 10 Sep 2014 17:41:17 -0700, a écrit : > Just got this from Clang 3.4.2 on Linux x86-64: > > In file included from topology-x86.c:23: > /home/common/openmpi/svn-trunk/opal/mca/hwloc/hwloc191/hwloc/include/private/ > cpuid-x86.h:67:3: warning: extension used

Re: [hwloc-devel] Migrate Trac tickets -> Github issues

Jeff Squyres (jsquyres), le Fri 12 Sep 2014 10:44:03 +, a écrit : > I did a test import of hwloc's Trac tickets to githib -- what do you think? > > https://github.com/ompiteam/hwloc-test-ticket-import/issues It looks good to me. I have unwatched the github hwloc project. Samuel

Re: [hwloc-devel] upcoming feature removal

Brice Goglin, le Mon 03 Nov 2014 11:49:02 +0100, a écrit : > * kerrighed support (single-system image): planned for removal since > 2012, see https://github.com/open-mpi/hwloc/issues/73 Right, Kerrighed is mostly discontinued. > I am also considering this change that shouldn't break existing

Re: [hwloc-devel] [PATCH] utils/hwloc/Makefile.am: fix install-man race condition

Peter Korsgaard, le Tue 12 May 2015 16:09:55 +0200, a écrit : > Make install contains a race condition in utils/hwloc, as both > install-exec-hook (through intall-exec) and install-data trigger > install-man: I'm surprised: isn't make supposed to handle this kind of dependency concurrency?

Re: [hwloc-devel] hwloc-1.11 failure with pgi compiler

Hello, Paul Hargrove, le Mon 20 Jul 2015 23:12:10 -0700, a écrit : > I believe the following inline x86 asm is correct and more robust than the > existing code that pgi appears to reject: Indeed, in the 32bit case, we don't need to shuffle between 32 and 64bit values, so it's simpler to just use

Re: [hwloc-devel] hwloc-1.11 failure with pgi compiler

Brice Goglin, le Tue 28 Jul 2015 16:13:49 +0200, a écrit : > and your commit is slightly different: (s/xchg/mov/ and removed last line). xchg is spurious here, mov is enough. I didn't remove the last line, I just kept the original source, which uses +a instead of =a and a. > FWIW, in master we

Re: [hwloc-devel] hwloc-1.11 failure with pgi compiler

Paul Hargrove, le Tue 21 Jul 2015 16:15:24 -0700, a écrit : > I am glad you asked me to test widely, because I did find 2 compilers that > rejected my version with "=r" and one that generated bad code for that case. What kind of bad code was it generating? Perhaps it was due to not using an early

<    1   2   3   4   5   >