2013-08-02  

  * 6b62d586 man/man1/papi_avail.1 man/man1/papi_clockres.1

  man/man1/papi_command_line.1...: Update the manpages for a pending 5.2

  release.  New pages for PAPI[F]_epc and papi_version.

  * 1ae08835 src/linux-common.c: try to properly detect number of sockets  Use

  totalcpus rather than ncpu in the calculation.  This change fixes things on a

  Sandybridge-EP machine.  We should maybe find a more robust way to detect

  this.

  * 79c37fbf .../perf_event_uncore/tests/perf_event_uncore.c

  .../tests/perf_event_uncore_multiple.c: perf_event_uncore: have tests skip if

  component disabled rather than fail

  * 638ccf6b .../perf_event_uncore/perf_event_uncore.c: perf_event_uncore:

  change order of uncore detection logic  This way it will report an error of

  "no uncore found" before it reports "not enough permissions".  That way a

  user won't waste time getting permissions only to find out they didn't have

  an uncore anyway.

  * 30582773 src/components/perf_event/pe_libpfm4_events.c: perf_event: fix

  papi_native_avail output  A recent change of mine that added stricter error

  checking for libpfm4 event lookup broke event enumeration on perf_event,

  specifically papi_native_avail output.  libpfm4 will return an error on some

  events if no UMASK or improper UMASK is supplied, but papi_native_avail

  always wants to print the root event and umasks separately.  this temporary

  fix just ignores libpfm4 umask errors; we might in the future want to

  properly indicate which events are only valid when certain umasks are

  present.

  * c7612326 src/utils/native_avail.c: papi_native_avail: fix empty component

  case  If a component had no events, papi_native_avail would ignore the error

  returned by PAPI_enum_cmp_event( PAPI_ENUM_FIRST ); and try to print a first

  event anyway.

  * e1b064eb .../perf_event_uncore/perf_event_uncore.c: perf_event_uncore:

  disable component if no events found  This can happen on older (pre 3.6)

  kernels with the new libpfm4 that does proper uncore detection.

2013-08-01  

  * 9a54633a src/components/host_micpower/linux-host_micpower.c

  src/components/infiniband/linux-infiniband.c

  src/components/nvml/linux-nvml.c...: Components: Use the cuda dlopen fix all

  cases.  See 4cb76a9b for details, the short version is if you call dlopen

  when you have been statically linked to libc, it gets ugly.

2013-07-31  

  * dbc44ed1 src/components/perf_event/pe_libpfm4_events.c

  .../perf_event_uncore/perf_event_uncore.c

  .../perf_event_uncore/peu_libpfm4_events.c: perf_event libpfm4 events --

  correctly handle invalid events  It was possible for event names to be

  obtained from libpfm4 during enumeration that were not valid events.  This

  usually happens with uncore events, where the uncore is listed as available

  based on cpuid but when libpfm4 tries to get the uncore type from the kernel

  finds out it is unsupported.  This change makes this properly fail, instead

  of just returning "0" for all the event paramaters (which is a valid event on

  x86).  Also make this change in the regular perf_event component, even though

  it is less likely to happen in practice.

  * 4720890a .../perf_event_uncore/perf_event_uncore.c: perf_event_uncore:

  remove check_permissions() test  It was trying to see if an EventSet was

  runnable by using the current permissions and adding the PERF_HW_INSTRUCTIONS

  event. That doesn't really make sense on uncore.  The perf_event component

  uses this test to try to give errors early, at set_opt() time rather than at

  the first run time, although in practice now we can probably make intelligent

  guesses based on the current permission levels.

  * 113d35f7 .../perf_event_uncore/perf_event_uncore.c: perf_event_uncore:

  remove unused kernel workarounds  uncore only works on Linux 3.6 or newer so

  all of the pre-2.6.35 workarounds aren't necessary.  If someone has

  backported the uncore support to kernels that old, hopefully they've also

  backported all the other bugfixes too.

2013-07-25  

  * 4cb76a9b src/components/cuda/linux-cuda.c: Trial fix for the cuda component

  static libc linking issue.  Weak link against _dl_non_dynamic_init, this

  appears in my limited testing to be in gnu libc.a and not in the so.  For

  background, it was reported by Steve Kaufmann that statically linking tools

  with a PAPI library configured with the CUDA component segfaulted. It appears

  that calling any of the dynamic linker functions from a static executable is

  asking for pain.  See Trac bug 182

  https://icl.cs.utk.edu/trac/papi/ticket/182

2013-07-24  

  * ad47cfb9 src/configure src/configure.in: Add linux-pfm-ia64 to configure 

  I'm not sure if this is enough to fix itanium support but it's a start.

  * 098294c5 src/components/example/tests/example_basic.c

  .../example/tests/example_multiple_components.c: Fixed tests for example

  component. Both tests failed due to incorrect check of the components PAPI

  has been configured with.

2013-07-23  

  * c0c4caf4 src/linux-memory.c src/papi_events.csv: Add initial support for

  IBM POWER8 processor  Add initial support for IBM POWER8 processor  The IBM

  POWER8 processor (to be publicly announced at some future date) has some

  preliminary support in libpfm with a subset of native events.  These

  POWER8-related libpfm changes were pulled into PAPI on July 3, so further

  updates in PAPI were required to support this new processor.  This patch adds

  that required support.  NOTE: Due to the fact that only a subset of native

  events have been publicised at this point (and pushed into libpfm), not all

  of the usual PAPI preset events have corresponding native events. The rest of

  the POWER8 native events will be pushed upstream once they are verified, and

  then we can flesh out the PAPI preset events.  With this initial POWER8

  support patch, 5 of the ctests and ftests fail, compared to 3 when PAPI is

  run on a POWER7. At least one of the failing testcases is due to testing

  being done on an early POWER8 processor with some known hardware problems. We

  presume the number of failing tests will decrease once we have GA-level

  hardware to test on. 

2013-07-22  

  * 6c231d1a src/configure: Rerun autoconf  for f4ec143e Correct versioning of

  libpapi.so

  * f4ec143e src/configure.in: Correct versioning of libpapi.so  The configure

  for linux always set the soname to libpapi.so.  This causes problems when

  /sbin/ldconfig tries to update the library information on linux.  The shared

  library is installed as /lib{64}/libpapi.so.$VERSION, but the shared library

  has the soname of libpapi.so.  ldconfig makes a symbolic link from

  /lib/libpapi.so to the actual versioned shared library,

  /lib/{64}/libpapi.so$VERSION. The configure should get the soname correct to

  avoid creating this symbolic link.  This patch only addresses the issues for

  some of the possible platforms and similar patches may be needed for other

  platforms. 

2013-07-19  

  * 92356bbd src/papi.c src/threads.c src/threads.h: Attempt to fix a memory

  leak in fork2 test.  Fork2 does the following: PAPI_library_init() fork(); / 

    \ parent   child wait()     PAPI_shutdown()	->

  _papi_hwi_shutdown_global_threads() -> foreach(threadinfo we allocated):

  _papi_hwi_shutdown_thread() PAPI_library_init()  _papi_hwi_shutdown_thread

  checks who allocated a ThreadInfo entry in the global list, and will only

  free it if our thread did the allocation.  When threading is not initialized,

  we fall back to getpid(), now in the child process, the one ThreadInfo item

  on the list was allocated by our parent, so at shutdown time we don't free

  this, and thus leak it.  Solution is to add a parameter to

  _hwi_shutdown_thread to force shutdown even if we didn't allocate it. At

  _papi_hwi_shutdown_global_threads() time, who cares, its closing time.

  * c04d908e src/cpus.c: Fix a deadlock in _papi_hwi_lookup_cpu().  If cpu_num

  is not found by _papi_hwi_lookup_cpu(), _papi_hwi_initialize_cpu() calls

  insert_cpu(), which locks CPUS_LOCK, which was already held by

  _papi_hwi_lookup_cpu().

  * efac24c4 src/components/micpower/linux-micpower.c: micpower: fix return

  value check  Also add a time check at stop time.

2013-07-16  

  * b9fd9dd1 src/configure src/configure.in: configure: Fix AIX build 

  perfctr_ppc was not the only system that relied on ppc64_events.h, power*.h,

  and friends. First run at a fix is -Icomponents/perfctr_ppc for the C and F

  flags...

  * 46042e68 src/components/micpower/linux-micpower.c: micpower: update some

  indexing code

2013-07-15  

  * 5220e7d2 INSTALL.txt: INSTALL.txt: typo  --with-arch=, not --arch=; Thanks

  to Karl Schulz for catching this.

  * 207e0ee0 src/papi_libpfm_events.h: papi_libpfm_events: needs include files

  for types.  Include papi.h and papi_vector.h for papi_vector_t and

  PAPI_component_info_t

  * d96c01c7 src/components/perfctr/perfctr.c: perfctr: cleanup a warning 

  Include papi_libpfm_events.h for _papi_libpfm_init() decl.

  * 367e1b38 src/components/perfctr/perfctr-x86.c

  src/components/perfctr/perfctr.c: perfctr: refactor out setup_x86_presets 

  The setup_presets function served only to call _papi_libpfm_init, so we go

  the rest of the way and completly remove the function, calling

  _papi_libpfm_init directly from _perfctr_init_component.

  * 1ba38ce5 src/components/perfctr/perfctr-x86.c: perfctr: cleanup unused

  parameter warning.  The perfctr code was refactored to only call into the

  table loading code one time. This had the side effect of removing most of

  what setup_x86_presets does.

  * 02710ced src/configure src/configure.in: configure: remove debugging

  message  The compiler detection code had a stray AC_MSG_RESULT.

2013-07-12  

  * 028ce29d src/components/lustre/linux-lustre.c: lustre: use whole directory

  name as event  Gary Mohr reported that on a trial system he was seeing many

  events of the form fs3-* which were all chopped to fs3, not helpful.  I've

  not actually been able to figure out exactly how lustre names things, I've

  seen it described as  <fs>-<uid>  But have no clue what uid promisses.

2013-07-15  

  * 129d4587 src/papi.c: allow more than one EventSet attach to a CPU at a time

   This is necessary for perf_event_uncore support, as multiple uncores will

  want to attach to a CPU.  It looks like this change won't break anything, and

  the tests pass on my test machines.  I am a bit concerned about

  cpu->running_eventset, though no one seems to use that value...

  * bcda5ddd src/components/perf_event_uncore/tests/Makefile

  .../tests/perf_event_uncore_nogran.c: perf_event_uncore: remove

  perf_event_uncore_nogran test  It is unnecessary after recent changes to the

  uncore component.

  * b1b9f654 src/components/perf_event_uncore/tests/Makefile

  .../tests/perf_event_uncore_cbox.c: perf_event_uncore: add

  perf_event_uncore_cbox test  This adds a non-trivial test of the CBOX

  uncores. It turned up various bugs in the PAPI uncore implementation.

  * df1b6453 src/linux-common.c: linux: properly set hwinfo->socket value  It

  was being derived from hwinfo->ncpu but being calculated before hwinfo->ncpu

  was set.

2013-07-13  

  * ee537448 .../perf_event_uncore/perf_event_uncore.c

  .../perf_event_uncore/peu_libpfm4_events.c

  .../perf_event_uncore/peu_libpfm4_events.h: perf_event_uncore: properly

  report number of total counters available

  * 7eb93917 src/components/perf_event/Rules.perf_event

  src/components/perf_event/pe_libpfm4_events.c

  src/components/perf_event/pe_libpfm4_events.h...:

  perf_event/perf_event_uncore/libpfm4 -- rearrange files  Give perf_event and

  perf_event_uncore copies of papi_libpfm4_events to work with, as they will

  have different needs for the code.  Get rid of the perf_event_lib stuff.  It

  was a hack to begin with and in the end not much code will be shared.  Maybe

  we can re-share things once uncore support is complete.

2013-07-12  

  * 6810af2a src/components/perf_event/perf_event.c

  .../perf_event_uncore/perf_event_uncore.c src/papi_libpfm4_events.c...:

  papi_libpfm4: properly call pfm_terminate() in papi_libpfm4_shutdown

  * 010497f4 src/components/perf_event/perf_event.c

  .../perf_event_uncore/perf_event_uncore.c src/papi_libpfm4_events.c...: split

  papi_libpfm4_init()  split this function because the perf_event_uncore()

  component is going to want to initialize things differently than plain

  perf_event

  * d9023411 src/components/perf_event/perf_event.c: perf_event: on old kernels

  if SW Multiplex enabled, then report proper number of MPX counters available 

  it may be different than the amount HW supports

  * 7595a840 src/components/perf_event/perf_event_lib.c: perf_event: use

  PERF_IOC_FLAG_GROUP when resetting events  This ioctl argument specifies to

  reset all events in a group, so we don't have to iterate.  This argument

  dates back to the introduction of perf_event and it makes the code a bit

  cleaner.

  * f220fd19 src/ctests/Makefile src/ctests/reset_multiplex.c: Add

  reset_multiplex.c  PAPI_reset() potentially exercises different paths when

  resetting normal and multiplexed eventsets, so make sure we test both.

  * f784a489 src/components/lustre/linux-lustre.c: lustre: botched a conflict

  resolution  properly do error checking on addCounter()

  * c1350fc8 src/components/perf_event/perf_event.c

  src/components/perf_event/perf_event_lib.c

  src/components/perf_event/perf_event_lib.h: perf_event: move overflow and

  profile code out of common lib  the perf_event_uncore component doesn't need

  it

  * 8dde03fc .../perf_event_uncore/perf_event_uncore.c: perf_event_uncore:

  remove profiling and overflow code  perf_event doesn't support sampling or

  overflow on uncore

  * 30d23636 src/components/lustre/linux-lustre.c: lustre component: Several

  fixes  1. create a dynamic native events table in pathalogical cases, lustre

  can have lots of events.  2. resolve some warnings change signature of

  init_component properly error check addCounter  3. Add a preprocessor flag to

  fake interface Set LIBCFLAGS="-DFAKE_LUSTRE"

  * 7ef51566 .../perf_event_uncore/perf_event_uncore.c: perf_event_uncore:

  remove dispatch timer call  perf_event  doesn't support sampling on uncore

  events

  * 667661c6 src/components/perf_event/perf_event.c

  src/components/perf_event/perf_event_lib.c

  src/components/perf_event/perf_event_lib.h: perf_event: move rdpmc detection

  back into perf_event.c  It was in the perf_event_lib but uncore won't use the

  feature.

  * d46f01e1 .../perf_event_uncore/perf_event_uncore.c: perf_event_uncore:

  check the paranoid file  Disable the component if paranoid isn't 0 or lower,

  and we're not running as root.

  * e4ec67d1 src/components/perf_event/perf_event.c: perf_event and paranoid

  level 2  If paranoid level 2 (no kernel events) was set we were removing

  PAPI_DOM_KERNEL from the allowable domains  We were doing this even if the

  user was root.  This code checks for uid 0 and overrides the restriction.

  * c5501081 src/components/perf_event/perf_event_lib.c

  src/components/perf_event/perf_event_lib.h: rename sys_perf_event_open2()

  call back to sys_perf_event_open()  This was changed when merging code to

  avoid a conflict but wasn't renamed back whe the conflict was fixed.

2013-07-11  

  * e263ea60 src/configure src/configure.in: configure: libpfm selection logic

  rework  If configure detected perfctr it would force libpfm3 to be used, even

  with --with-perf_events, now force libpfm4 if perf_events is requested.

2013-07-10  

  * 7a3ce030 .../host_micpower/Makefile.host_micpower.in

  src/components/host_micpower/Rules.host_micpower

  src/components/host_micpower/configure...: Component: host_micpower  This is

  a component that exports power information for Intel Xeon Phi cards (MIC).

  The component makes use of the MicAccessAPI distributed with the Intel

  Manycore Platform Software Stack.

  k-mpss)

  * 9d9bd9c2 src/ctests/shlib.c: Fwd: Re: [Ptools-perfapi] ctests/shlib FAILED 

  Should have sent this to the papi devel list. -Will  -------- Original

  Message -------- Subject: Re: [Ptools-perfapi] ctests/shlib FAILED Date: Tue,

  09 Jul 2013 23:20:10 -0400 From: William Cohen <wcohen@redhat.com> To:

  ptools-perfapi@eecs.utk.edu  On 03/09/2012 03:40 PM, William Cohen wrote: > I

  was looking through the test results and found that ctests/shlib FAILED on

  all the machines I tested on because libm shared library is already linked

  in. There is no difference in the number of shared libraries before and after

  the dlopen. The test ctests/shlib fails as a reult of this. > > -Will >

  _______________________________________________ > Ptools-perfapi mailing list

  > Ptools-perfapi@eecs.utk.edu >

  http://lists.eecs.utk.edu/mailman/listinfo/ptools-perfapi >  I did some more

  investigation of this problem today.  I found that the lmsensor component

  implicitly pulls in the libm.  As an alternative, I wrote the attached patch

  that uses setkey() and encrypt() in libcrypt.so instead.  It works on various

  linux machines, but I do not know whether it is going to work on other OS. 

  -Will  >From c53c97e1de2d1c7dc0bca64d1906287ff73343c6 Mon Sep 17 00:00:00

  2001 From: William Cohen <wcohen@redhat.com> Date: Tue, 9 Jul 2013 22:37:27

  -0400 Subject: [PATCH] Avoid using libm.so for ctests/shlib because of

  implicit use in some components  The lmsensors component can implicitly pull

  in libm.so into the executable.  Unfortunately, the ctests/shlib test expects

  that libm.so is not loaded and will fail because there is no change in the

  count of shared libraries.  The patch uses libcrypt.so library setkey and

  encrypt functions to test PAPI_get_shared_lib_info( ) instead of libm.so

  library pow function. 

2013-07-09  

  * bdc9b34b .../tests/perf_event_amd_northbridge.c:

  Perf_event_amd_northbridge_test: Use buffer event_name instead of

  uncore_event  The variable uncore_event is initialized to NULL and is never

  changed during execution of the test. PAPI_add_named_event fails and the

  event set cannot be started. The correct event name is stored in event_name,

  replacing all occurrences of uncore_event with event_name therefore fixes the

  problem metioned above.

2013-07-08  

  * a1678388 src/components/micpower/linux-micpower.c: micpower:  Fix output in

  native_avail and component_avail. It uses cmp_info.name, not .short_name? 

  Native Events in Component: mic-power Name:   mic-power              

  Component for reading power on Intel Xeon Phi (MIC)  Should both match what

  is prepended to event names, so change .name from mic-power to micpower.

  * e0582f2d src/components/micpower/linux-micpower.c: Micpower: fix a typo 

  subsystem, not sybsystem...

  * c7b357ec INSTALL.txt: INSTALL.txt: update instructions for MIC.

  * 34a1124e src/components/perf_event_uncore/tests/Makefile

  .../tests/perf_event_amd_northbridge.c: Add perf_event_amd_northbridge test 

  The test should show how to write a program using AMD fam15h NB with a 3.9

  kernel.  Once libpfm4 gets updated we can see if it's possible to also have

  the test properly run on 3.10 kernels (in that case the regular

  perf_event_uncore test should work w/o changes)

  * 41b6507c .../perf_event_uncore/tests/perf_event_uncore.c

  .../tests/perf_event_uncore_multiple.c: Make perf_event_uncore tests use

  PAPI_get_component_index()  They were open-coding the component name search

  for no good reason.

2013-07-05  

  * abf38945 src/papi_libpfm4_events.c: avoid having a "default" PMU for the

  uncore component  on the main CPU component we have a "default" PMU where you

  can leave out the PMU part of the event name.  This is unnecessary and

  sometimes confusing on uncore, so always print the full event name if it's an

  uncore PMU.

  * b9fe5c3e .../perf_event_uncore/tests/perf_event_uncore.c

  .../tests/perf_event_uncore_multiple.c: Update perf_event_uncore tests to

  properly fail if they don't have enough permissions

  * 32ae1686 .../perf_event_uncore/tests/perf_event_uncore.c:

  perf_event_uncore_test : properly use uncore component  The sample code was

  still hardcoding to component "0" which shouldn't have worked.  Thanks to

  Claris Castillo for pointing out this problem.

  * 59e73b51 src/papi_libpfm4_events.c: have _papi_libpfm4_ntv_name_to_code

  properly check pmu_type  With the existing code, uncore events were being

  found by the perf_event component even when that component has uncore events

  distabled.

2013-07-03  

  * a01394eb .../tests/perf_event_uncore_lib.c: perf_event_uncore: fix ivb

  event in uncore test  Now that libpfm4 officially supports plain ivb uncore,

  make sure the test event we were using matches what libpfm4 supports.

2013-07-01  

  * f10342a8 src/utils/cost.c: Clean up option handling in papi_cost  The

  papi_cost used strstr to seach for the substring that matched the option. 

  this is pretty inexact.  Made sure that the options matched exactly and the

  option argments for -b and -t were greater than 0. Also make papi_cost print

  out the help if there was an option that it didn't understand. 

  * b5adc561 src/utils/native_avail.c: Clean up option handling for

  papi_native_avail  Corrected the help to reflect the name of the option

  "--noumasks". Print error message if the "-i", "-e", and "-x" option

  arguments are invalid. Avoid using strstr() for "-h", use strcmp instead.

  Also check for "--help" option. 

  * 8933be9b src/utils/decode.c: Clean up option handling in papi_decode 

  papi_decode used strstr() to match options; this can lead to inexact matchs.

  The code should used strcmp instead.  Make sure command name is not processed

  as an option.  Also print help iformation is some argument is not understood.

  * d94ac43a src/utils/component.c: Improve option matching in papi_component

  and add "--help" option 

  * bb63fe5c src/utils/command_line.c: Add options to papi_command_line man

  page and improve opt handling  Add options mention in the -h to the man page.

   Also improve the matching of the options. 

  * 09059c82 doc/Makefile src/utils/version.c: Add information for papi_version

  to be complete 

  * 4f2eee8c src/configure src/configure.in: add a --disable-perf-event-uncore

  option to configure

2013-06-29  

  * 901c5cc2 src/components/perf_event/perf_event.c

  src/components/perf_event/perf_event_lib.c

  .../perf_event_uncore/perf_event_uncore.c...: remove syscalls.h  it's no

  longer needed

  * 4d7e3666 src/Rules.perfmon2 src/components/perfmon2/Rules.perfmon2

  src/components/perfmon2/perfmon.c...: move perfmon modules to their own

  component directory

  * a7e9c5f1 src/Rules.perfctr src/Rules.perfctr-pfm

  src/components/perfctr/Rules.perfctr...: move perfctr files to

  components/perfctr directory  verified that perfctr-x86 still builds and

  works  perfctr_ppc has all the files to build, but it doesn't work. It looks

  like no one has tried to build perfctr-ppc for a very very long time.

2013-06-27  

  * e9dec1fd src/ctests/hl_rates.c src/papi.h src/papi_fwrappers.c...: debugged

  versions of these files

  * e282034e src/utils/native_avail.c: native_avail: Fix parse_unit_mask code 

  Reported by Steve Kaufmann -------------------------- I noticed while

  developing a new component that the output from papi_native_avail was

  incorrectly presented for the component. I believe this is because the ":::"

  prefix is not being taken into account, so the base event name is interpreted

  as a unit mask and is prepend with a : before each legitimate unit mask

  associated with the event. I think this is just now happening because mine is

  the first component that has unit masks. I have include a fix below. The

  output of the unit masks by papi_native_avail now appears correctly for my

  component.  Thanks, Steve

2013-06-26  

  * ff096786 src/ctests/fork2.c: fork2: Return fork2 test to its old

  functionality  Once upon a time fork2 did: PAPI_library_init() … if (

  fork() == 0) PAPI_shutdown() PAPI_library_init() …

2013-06-25  

  * 978d0d3d src/examples/PAPI_add_remove_event.c src/papi.c: Modify

  PAPI_list_events functionality to match documentation. You can now pass in a

  NULL event array and a zero count to get back the valid number of events.

  This can then be used to allocate the array and retrieve the exact number of

  events. Thanks to Nils Smeds and Alain Miniussi for pointing this out.

  * 13c52402 src/examples/PAPI_add_remove_event.c src/papi.c: Modify

  PAPI_list_events functionality to match documentation. You can now pass in a

  NULL event array and a zero count to get back the valid number of events.

  This can then be used to allocate the array and retrieve the exact number of

  events. Thanks to Nils Smeds and Alain Miniussi for pointing this out.

  * 656e703e src/ctests/zero_fork.c: zero_fork ctest : make documentation match

  code

  * 96aad0c7 src/ctests/forkexec.c: forkexec ctest : make comments match code

  * b7c70953 src/ctests/forkexec4.c: forkexec4 ctest : make comments match the

  code

  * 7ffb0245 src/ctests/forkexec3.c: forkexec3 ctest : make documentation match

  code

  * 55ea846c src/ctests/forkexec2.c: forkexec2 ctest: have comments match what

  source does

  * 7a601e2a src/ctests/Makefile src/ctests/fork2.c: fork2 ctest: remove; was

  an exact duplicate of fork

  * 9deff49b src/ctests/fork.c: fork ctest: make comments match what file

  actually does

2013-06-24  

  * 2770d2c5 src/components/perf_event/perf_event_lib.c: perf_event: fix

  failure on ARM due to domain settings  forgot to git add the perf_event_lib.c

  file :(

  * bf7c4c50 src/components/perf_event/perf_event.c

  src/components/perf_event/perf_event_lib.h: perf_event: fix failure on ARM

  due to domain settings  On Cortex A8 and A9 it's not possible to set

  exclude_kernel (hardware does not support it).  Make sure the rdpmc detection

  code doesn't try to set exclude_kernel.

2013-06-18  

  * 2b1433d8 src/ctests/all_native_events.c src/ctests/get_event_component.c:

  ctests: Skip calling into disabled components.  This patch fixes a problem

  that was causing two test cases to abort when they were run on a system which

  has disabled components.  Code was added to check if the component is

  disabled and just go to the next component in the list when the check is

  true.  This prevents calls to code in components which may abort because the

  component was unable to initialize itself correctly.  Thanks to Gary Mohr and

  Chuck LaCasse from Bull for reporting.

2013-06-14  

  * 1872453c src/testlib/do_loops.c: testlib: don't change the iter count  The

  first argument to do_misses is an iteration count, for some reason the code

  was dividing this in half before doing work. Most places that call do_misses

  call it as do_misses ( 1, ...)  void do_misses( int n, int bytes ) { {...} n

  = n / 2; for ( j = 0; j < n; j++ ) {  1/2 == 0; so our do_misses call was

  usually not.  Thanks Nils Smeds for reporting.

2013-06-12  

  * c113e5b6 src/components/infiniband/Makefile.infiniband.in

  src/components/infiniband/Rules.infiniband

  src/components/infiniband/configure...: Infiniband component: switch over to

  weak linking  Thnaks to Gary Mohr for the patch.

  ---------------------------------- The infiniband component needs include

  files and libraries from both the infiniband ibmad and ibumad packages.  When

  these packages are installed on a system, both packages normally install

  their files in the same place (includes in /usr/include/infiniband and

  libraries in /usr/lib64).  The current component configure script allows you

  to provide a single include path and a single library path which gets used to

  access files from both packages.  If these two packages have different

  install prefixes (or you are trying to build from install images of each

  package which are not located under the same directory) then the configure

  script fails because it can not find all the files it needs.  These changes

  modify the configure script to replace the include and library dir's with an

  ibmad_dir and ibumad_dir and then uses the correct packages directory when

  looking for includes and libraries from that package.  This makes it work

  like the cuda and nvml components with respect to configuring how to find

  files from a package the component depends on.  There are also changes in

  this patch file to remove an unneeded variable in the dlopen code to resolve

  some defects reported by coverity.

2013-06-11  

  * d5be5643 src/components/rapl/tests/rapl_basic.c: rapl tests: make the error

  messages a little more verbose

  * 0c9f1a8c src/run_tests_exclude.txt src/run_tests_exclude_cuda.txt:

  run_tests_exclude files: Exclude a template file 

  ------------------------------------------- It also adds the cpi.pbs file to

  the list of files to excluded when the tests are run. This file is just a

  template and attempts to run it hang the run_tests script on our systems.

  -------------------------------------------

  * 0a063619 src/run_tests.sh: run_tests.sh: fix exclude check.  The script

  failed to remove .cu files, this patch fixes the check. Thanks Gary Mohr for

  reporting/patching.

2013-06-10  

  * 87399477 src/components/cuda/linux-cuda.c: cuda component: Address a

  coverity issue  The library linking code saved return values in a local var

  but never used them. Thanks to Gary Mohr for submitting this patch.

  * 99b5b685 src/components/coretemp/tests/coretemp_basic.c: coretemp_basic:

  update test to properly enumerate events  The code was old and was searching

  the entire native event list for ones that started with "hwmon".  This

  updates the test to first find the coretemp component, then enumerate all

  events contained within.

  * b5c0795b src/components/rapl/tests/rapl_overflow.c: rapl component: address

  potential looping issue in test.  A rapl component test has a do/while which

  only exited when PAPI_add_named_event returned 0 ( and only 0; the PAPI_E*

  error codes would not terminate a while( retval ) loop), this felt fragile,

  minimal checks are now inplace.

  * 4e9484a5 src/components/rapl/tests/rapl_overflow.c: rapl components:

  coverity fixes  Reported/patched by Gary Mohr -----------------------------

  The rapl component also has 1 defect in a test case.  The complaint is that

  there is code that can never be executed.  But this one is not as clear, it

  says that you can not exit the do/while loop that preceeds a test of retval

  until retval=0 which means the test can never be true.  The patch I am

  providing is to again remove the if test and its contents.  But I am

  concerned that the do/while loop preceeding the test could result in a hard

  loop that would hang the test case forever.  It seems to me like something

  should also be done to insure the loop will exit at some point.  Here is a

  patch that provides at least part of the fix: -----------------------------

  * 0a533810 src/components/net/tests/net_values_by_name.c: net components:

  coverity fixes  Reported/patched by Gary Mohr -----------------------------

  The net component has one defect in one of the test cases.  The complaint is

  that there is code that can never be executed.  There is a test to see if

  event_count == 0 which can never be true at that place in the code.  So I

  removed the if statement and its contents.  Here is the patch:

  -----------------------------

2013-06-07  

  * b784b063 src/components/nvml/Rules.nvml src/components/nvml/configure

  src/components/nvml/configure.in...: nvml: Apply Gary Mohr's dlopen patch. 

  Move the nvml component over to using the dlopen and weak linking

  infrastructure of the cuda component. Thanks, Gary.

  * d6505b76 src/components/rapl/utils/rapl_plot.c: rapl: update the rapl_plot

  utility  Get the event names by enumerating the ones available with the RAPL

  component rather than having a hard-coded list.

  * 2094c5b1 src/components/rapl/linux-rapl.c: rapl: add better error messages

  on component init failure

  * d0e668fb src/ctests/Makefile src/ctests/high-level.c

  src/ctests/hl_rates.c...: First round of changes to implement a PAPI high

  level event per cycle call. Untested.

2013-06-05  

  * 63074f82 src/components/rapl/linux-rapl.c: rapl: Add Ivb-EP support  The

  Intel docs are spotty on what is actually supported. They state: 14.7.2 RAPL

  Domains and Platform Specificity The specific RAPL domains available in a

  platform varies across product segments. Platforms targeting client segment

  support the following RAPL domain hierarchy: * Package * Two power planes:

  PP0 and PP1 (PP1 may reflect to uncore devices) Platforms targeting server

  segment support the following RAPL domain hierarchy: * Package * Power plane:

  PP0 * DRAM

2013-05-31  

  * 31b4702d src/cpus.c: cpus.c: Don't run init_thread/shutdown_thread for

  disabled components.

2013-05-29  

  * c48087d2 ChangeLogP511.txt RELEASENOTES.txt: Grab the updated ChangeLog

  from 5.1.1  Create a ChangeLog and update RELEASENOTES for a 5.1.1 release.

2013-05-24  

  * d1c8769e src/components/perf_event/tests/Makefile

  src/components/perf_event/tests/event_name_lib.c

  .../perf_event/tests/perf_event_user_kernel.c: Add perf_event user/kernel

  domain test  This will be useful if/when we start handling domains properly.

  * 89e1aeba src/components/perf_event/tests/Makefile

  src/components/perf_event/tests/event_name_lib.c

  src/components/perf_event/tests/event_name_lib.h...: Add perf_event offcore

  response test  Does a quick check to see if offcore response events are

  working.

  * bda86616 .../perf_event_uncore/perf_event_uncore.c

  src/ctests/get_event_component.c src/papi_internal.c: Some more ctest fixes

  involving disabled components.  We enforce disabled components sometime in

  the PAPI routines and sometimes in the components themselves.  A bit

  confusing.  It is tough with perf_event and perf_event_uncore because we

  share libpfm4 by both, so the naming library for perf_event_uncore will be

  active even if the component is disabled, which can cause some confusing

  results if your test code ignores PAPI_ENOCMP error messages and accesses a

  disabled component anyway.  This at least fixes our test cases, we might have

  to revisit this later.

  * b596621e doc/Doxyfile-common papi.spec src/Makefile.in...: Bump version

  numbers  Call this 5.2.0.0 simple because its greater than (and some

  components are completely incompatible with) 5.1.1

  * eb77a91e .../perf_event_uncore/perf_event_uncore.c src/papi.c: Disallow

  enumerating events on disabled components.  This was causing segfaults on

  tests where enumeration was trying to enumerate uncore events on machines w/o

  uncores.

  * 4e991a8a .../perf_event/tests/perf_event_system_wide.c:

  perf_event_system_wide: SKIP instead of FAIL if we don't have proper

  permissions

  * 7654bb1f src/Makefile.inc src/components/perf_event/tests/Makefile

  .../perf_event/tests/perf_event_system_wide.c...: move the perf_event

  specific tests to be with their component  This means the perf_event tests

  will only be run if perf_event is enabled

  * d82e343f src/ctests/perf_event_uncore_multiple.c:

  ctests/perf_event_uncore_multiple: Improve this test a bit

  * b1a594bf src/perf_events.c src/sys_perf_event_open.c: Remove the no-longer

  needed perf_events files  Now we use the versions in the

  components/perf_event directory

  * a9a277f3 src/Makefile.in src/Makefile.inc src/configure...: Split up

  CPUCOMPONENT configure variable  Now it is CPUCOMPONENT_NAME CPUCOMPONENT_C

  CPUCOMPONENT_OBJ This allows having setups with no CPUCOMPONENT set

  (perf_event used as a component) while keeping backward compatible with

  non-component CPU components.  This has been tested on perf_event and

  perfctr.  It might break other architectures, so test if you can.

  * 69e29526 src/configure src/configure.in: configure: have --with-components

  append comonents to existing value  This allows configure to earlier set the

  components value to include "perf_event" if detected and then later append

  the values passed in with --with-components

  * 9d28df4c src/components/perf_event/Rules.perf_event

  src/components/perf_event/perf_event.c

  src/components/perf_event/perf_event_lib.c...: add perf_event and

  perf_event_uncore components  This adds perf_event as a standalone component.

  Currently it is not compiled or built, some changes need to be made to the

  build system before this will work.

2013-05-21  

  * ea996661 src/components/cuda/linux-cuda.c: eliminate warnings of unused

  vars

  * 691bf114 src/components/cuda/linux-cuda.c: eliminate warnings of unused

  vars

  * 221bfdab src/components/cuda/linux-cuda.c

  src/components/cuda/tests/HelloWorld.cu: Problem with cleanup_eventset():

  after destroying the CUDA eventset, update_control_state() is called again

  which operates on the already destroyed eventset.

2013-05-17  

  * 84925f50 src/components/cuda/linux-cuda.c: When adding multiple CUDA events

  to an event set, PAPI_add_event() error 14 (CUPTI_ERROR_NOT_COMPATIBLE) is

  being raised from the CUPTI library.  Turns out that the CUDA update control

  state wasn't cleaning the event set up properly before adding new events.

  It's fixed now.

  * 2337aa3a src/perf_events.c: perf_event: allow running with

  perf_event_paranoid is 2  perf_event_paranoid set to 2 means allow user

  monitoring only (no kernel domain).  The code before this mistakenly disabled

  all events in this case. Also set the allowed domains to exclude

  PAPI_DOM_KERNEL.

2013-05-16  

  * 617d9fbb src/papi_events.csv: papi_events.csv Revert a little mishap in

  adding ivbep support  Somehow the contents of papi_hl.c ended up in the

  events file.

  * 2aff4596 src/papi_events.csv: Add identifier for ivb_ep

  * 1810ddf9 src/papi_libpfm4_events.c src/papi_libpfm4_events.h

  src/perf_events.c: papi_libpfm4_events: allow specifying

  core/uncore/os_generic PMUs  This allows you to specify you only want your

  perf_event/libpfm4 based component to only export the PMU types you want. 

  Now we can have an uncore-only component.

  * 6554f3f0 src/papi_libpfm4_events.c: papi_libpfm4_events.c: only enable

  presets for component 0  If we have multiple events using libpfm4, we only

  want to load the presets if it is component 0.

  * 6a4a4594 src/papi.c: PAPI_get_component_index() was matching names

  improperly  For example, it was matching perf_event and perf_event_uncore as

  the same component.

  * 1b94e157 src/papi_hl.c: papi_hl.c : fix IPC calculation  I broke it a while

  back while trying to clear out use of MHz.  The code was uncommented and very

  confusing.  It is slightly better now.

  * 92d4552e src/papi_libpfm4_events.c src/papi_libpfm4_events.h

  src/perf_events.c: papi_libpfm4_events: code changes to allow multiple

  component access  the PAPI libpfm4 code has been modified to allow multiple

  users at once.  This will allow multiple components to use libpfm4, for

  example a CPU component and an uncore component.

  * 7902b30e src/cpus.c: cpus: fix debug compile  I always forget to compile

  with --with-debug and miss changes in the DEBUG statements.

2013-05-15  

  * 7ddc05ff src/cpus.c src/cpus.h: cpus.c: Add reference count to cpu

  structure  It is possible to have multiple eventsets all attached to the same

  CPU, as long as only one eventset is running at a time.  At EventSet cleanup,

  PAPI would free the CpuInfo_t structure even if other EventSets were still

  using it.  This patch adds a reference count to the structure and only frees

  it after the last user is cleaned up.  I also fixed a few locking bugs,

  hopefully I didn't introduce any new ones.

  * 6a61f9a2 src/cpus.c: more cleanup of the cpus.c file  mostly formatting and

  added comments.

  * 710d269f src/cpus.c src/cpus.h src/papi.c...: cleanup cpus.h  It had a lot

  of extraneous stuff in it.  Also make sure it only gets included in files

  that need it.

  * 422226c9 src/papi.c: papi.c: add some extra debug messages

  * b1297058 src/cpus.c: Clean up cpus.c a bit  Tracking down a segfault in the

  cpu attach cleanup code.

  * 7b6023cf src/ctests/perf_event_system_wide.c:

  ctests/perf_event_system_wide: much improved output  It segfaults at the end

  though, unclear if this is a bug in the test or a bug in PAPI.  Will

  investigate.

  * 38397aa3 src/components/cuda/configure src/components/cuda/configure.in

  src/components/cuda/linux-cuda.c...: Cuda component: Update library search

  path  From Gary Mohr: It turns out that with the changes I gave you the path

  to the libcuda.so library is still hard coded to /usr/lib64.  This assumes

  that the NVIDIA-Linux package is installed on the system where the build is

  being done.  In Bull's case (and probably other users also) this is not

  always the case.  To add the flexibility we need, I have added a new

  configure argument to the cuda configure script.  The new argument is

  "--with-cudrv_dir" and it allows the user to specify where the cuda driver

  package (ie: NVIDIA-Linux) to be used for the build can be found.  This new

  argument is optional and if not provided a value of "/usr" will be used. This

  allows existing configure calls to continue to work like before.

  * f8873d1c src/ctests/perf_event_system_wide.c:

  ctests/perf_event_system_wide: clean up the output a lot  Still working on

  understanding it.

  * ebf20589 src/ctests/perf_event_system_wide.c: perf_event_system_wide:

  testing various DOMAIN and GRANULARITY settings  pushing the limits of

  PAPI/perf_event trying to see why system-wide measurement doesn't work.

2013-05-14  

  * 0c1ef3f5 src/components/cuda/linux-cuda.c: CUDA component: Update

  description field  Also removes a strcpy in the init code, which overwrote

  the name field. Thanks to Gary Mohr

  * 474fc00e src/ctests/perf_event_uncore_lib.c: Add AMD fam15h northbridge

  event to ctests/perf_event_uncore_lib.c

2013-05-13  

  * cf56cdac src/perf_events.c: perf_event component: update error returns 

  This passes more error return values back to PAPI. Before this change a lot

  of places were hardcoded to PAPI_EPERM even if sys_perf_event_open() was

  reporting a different error.

  * c824471b src/ctests/Makefile src/ctests/perf_event_system_wide.c

  src/ctests/perf_event_uncore.c...: Update the perf_event specific tests. 

  This adds a few more uncore tests, which are currently showing some bugs in

  the implementation.  The tests all need root permissions to run, so should

  default to "SKIPPED" for most users.

2013-05-08  

  * e0204914 src/configure src/configure.in: Force the use of pthread_mutexes

  on ARM  This lets the system libraries worry about the best way to define

  mutexes, rather than trying to hand-code in assembly around all of the

  various issues there are with atomic instructions in the ARM architecture. 

  It might make sense to enable this for *all* Linux architectures, but for now

  just do it for ARM.

  * f21b1b27 src/linux-lock.h: Commit 59d3d7584b2925bd05b4b5d0f4fe89666eb8494a

  removed the definition of mb().  mb() was defined as rmb().  This just

  corrects it back.   (Note from VMW -- this fixes some things, but ARM still

  won't build on a Cortex A9 pandaboard due to the use of the "swp"

  instruction. Proper fix is probably to enforce posix-mutexes on ARM)