Re: [PATCH 1/3] perf report: Fix OOM error in TUI mode on s390

On 5/22/19 8:08 PM, Arnaldo Carvalho de Melo wrote: > Em Wed, May 22, 2019 at 04:45:59PM +0200, Thomas Richter escreveu: > . >> >> This size kills the TUI interface when executing the following >> code: >> >> process_sample_event() >> hist_entry_iter__add() >>

Re: WARN_ON_ONCE() hit at kernel/events/core.c:330

On 4/9/19 10:53 AM, Mark Rutland wrote: > On Mon, Apr 08, 2019 at 11:50:31AM +0200, Peter Zijlstra wrote: >> On Mon, Apr 08, 2019 at 10:22:29AM +0200, Peter Zijlstra wrote: >>> On Mon, Apr 08, 2019 at 09:12:28AM +0200, Thomas-Mich Richter wrote: >> . >> &g

Re: [PATCH] perf/report: [RFC] Handling OOM in perf report

On 4/9/19 12:42 PM, Jiri Olsa wrote: > On Mon, Apr 01, 2019 at 04:20:00PM +0200, Thomas Richter wrote: > > SNIP > >> perf_session__process_event() returns to its caller, where -ENOMEM is >> changed to -EINVAL and processing stops: >> >> if ((skip = perf_session__process_event(session, event,

Re: WARN_ON_ONCE() hit at kernel/events/core.c:330

On 4/8/19 11:50 AM, Peter Zijlstra wrote: > On Mon, Apr 08, 2019 at 10:22:29AM +0200, Peter Zijlstra wrote: >> On Mon, Apr 08, 2019 at 09:12:28AM +0200, Thomas-Mich Richter wrote: > >>> very good news, your fix ran over the weekend without any hit!!! >>> >>>

Re: WARN_ON_ONCE() hit at kernel/events/core.c:330

On 4/8/19 11:50 AM, Peter Zijlstra wrote: > On Mon, Apr 08, 2019 at 10:22:29AM +0200, Peter Zijlstra wrote: >> On Mon, Apr 08, 2019 at 09:12:28AM +0200, Thomas-Mich Richter wrote: > >>> very good news, your fix ran over the weekend without any hit!!! >>> >>>

Re: WARN_ON_ONCE() hit at kernel/events/core.c:330

On 4/8/19 10:22 AM, Peter Zijlstra wrote: > On Mon, Apr 08, 2019 at 09:12:28AM +0200, Thomas-Mich Richter wrote: >>> Does the below cure things? It's not exactly pretty, but it could just >>> do the trick. >>> >>> --- >>> diff --git a/kerne

Re: WARN_ON_ONCE() hit at kernel/events/core.c:330

On 4/4/19 3:03 PM, Peter Zijlstra wrote: > On Thu, Apr 04, 2019 at 01:09:09PM +0200, Peter Zijlstra wrote: > >> That is not entirely the scenario I talked about, but *groan*. >> >> So what I meant was: >> >> CPU-0 CPU-n >> >>

Re: WARN_ON_ONCE() hit at kernel/events/core.c:330

On 4/4/19 3:03 PM, Peter Zijlstra wrote: > On Thu, Apr 04, 2019 at 01:09:09PM +0200, Peter Zijlstra wrote: > >> That is not entirely the scenario I talked about, but *groan*. >> >> So what I meant was: >> >> CPU-0 CPU-n >> >>

Re: WARN_ON_ONCE() hit at kernel/events/core.c:330

On 4/4/19 3:03 PM, Peter Zijlstra wrote: > On Thu, Apr 04, 2019 at 01:09:09PM +0200, Peter Zijlstra wrote: > >> That is not entirely the scenario I talked about, but *groan*. >> >> So what I meant was: >> >> CPU-0 CPU-n >> >>

Re: WARN_ON_ONCE() hit at kernel/events/core.c:330

On 4/3/19 12:41 PM, Peter Zijlstra wrote: > On Wed, Apr 03, 2019 at 11:47:00AM +0200, Thomas-Mich Richter wrote: >> I use linux 5.1.0-rc3 on s390 and got this WARN_ON_ONCE message: >> >> WARNING: CPU: 15 PID: 0 at kernel/events/core.c:330 >> event_funct

Re: WARN_ON_ONCE() hit at kernel/events/core.c:330

On 4/3/19 12:41 PM, Peter Zijlstra wrote: > On Wed, Apr 03, 2019 at 11:47:00AM +0200, Thomas-Mich Richter wrote: >> I use linux 5.1.0-rc3 on s390 and got this WARN_ON_ONCE message: >> >> WARNING: CPU: 15 PID: 0 at kernel/events/core.c:330 >> event_funct

WARN_ON_ONCE() hit at kernel/events/core.c:330

I use linux 5.1.0-rc3 on s390 and got this WARN_ON_ONCE message: WARNING: CPU: 15 PID: 0 at kernel/events/core.c:330 event_function_local.constprop.79+0xe2/0xe8 which was introduced with commit cca2094605ef ("perf/core: Fix event_function_local()"). This is the WARN_ON_ONCE

Re: [PATCHv2 1/3] perf report: Display s390 diagnostic counter sets

On 01/21/2019 02:13 PM, Jiri Olsa wrote: > On Sun, Jan 20, 2019 at 07:18:14PM +0100, Jiri Olsa wrote: >> On Thu, Jan 17, 2019 at 11:00:53AM -0300, Arnaldo Carvalho de Melo wrote: >> >> SNIP >> >>> --- a/tools/perf/util/python-ext-sources >>> +++ b/tools/perf/util/python-ext-sources >>> @@ -25,6

Re: [PATCHv2 1/3] perf report: Display s390 diagnostic counter sets

On 01/17/2019 03:00 PM, Arnaldo Carvalho de Melo wrote: > erf report: Display arch specific diagnostic counter sets, starting with s390 > > On s390 the event bc000 (also named CF_DIAG) extracts the CPU > Measurement Facility diagnostic counter sets and displays them as > counter

Re: [Patch 1/4] perf report: Add function for verbose dump of raw data

On 01/11/2019 03:00 PM, Arnaldo Carvalho de Melo wrote: > Em Fri, Jan 11, 2019 at 12:52:56PM +0100, Thomas Richter escreveu: >> Add support to call an architecture dependend function to interpret >> raw data verbatim when dumping the perf.data file with >> option -D. > > Please add "per-arch" to

Re: [PATCH] perf/stat: Handle different PMU names with common prefix

On 10/26/2018 05:04 PM, Sébastien Boisvert wrote: > On 2018-10-23 11:16 a.m., Thomas Richter wrote: >> On s390 the CPU Measurement Facility for counters now supports >> 2 PMUs named cpum_cf (CPU Measurement Facility for counters) and >> cpum_cf_diag (CPU Measurement Facility for diagnostic

Re: [PATCH] perf/stat: Handle different PMU names with common prefix

On 10/26/2018 05:04 PM, Sébastien Boisvert wrote: > On 2018-10-23 11:16 a.m., Thomas Richter wrote: >> On s390 the CPU Measurement Facility for counters now supports >> 2 PMUs named cpum_cf (CPU Measurement Facility for counters) and >> cpum_cf_diag (CPU Measurement Facility for diagnostic

Linux 4.19.0 Build Error when CONFIG_ACPI not set.

When I compile the 4.19.0 Linux kernel, I get this build error: [root@f28 linux]# fgrep -r CONFIG_ACPI .config # CONFIG_ACPI is not set [root@f28 linux]# [root@f28 linux]# make CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h CC

Linux 4.19.0 Build Error when CONFIG_ACPI not set.

When I compile the 4.19.0 Linux kernel, I get this build error: [root@f28 linux]# fgrep -r CONFIG_ACPI .config # CONFIG_ACPI is not set [root@f28 linux]# [root@f28 linux]# make CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h CC

Re: [PATCH v2] perf test: S390 does not support watchpoints in test 22

On 09/28/2018 12:17 PM, Ravi Bangoria wrote: > Hi Thomas, > > On 09/28/2018 03:32 PM, Thomas-Mich Richter wrote: >> I can rework the patch to use the is_supported() member function. The >> down side is that the test does not show up in the list of executed tests >> an

Re: [PATCH v2] perf test: S390 does not support watchpoints in test 22

On 09/28/2018 12:17 PM, Ravi Bangoria wrote: > Hi Thomas, > > On 09/28/2018 03:32 PM, Thomas-Mich Richter wrote: >> I can rework the patch to use the is_supported() member function. The >> down side is that the test does not show up in the list of executed tests >> an

Re: [PATCH v2] perf test: S390 does not support watchpoints in test 22

On 09/28/2018 10:37 AM, Ravi Bangoria wrote: > Hi Thomas, > > On 09/28/2018 01:13 PM, Thomas Richter wrote: >> diff --git a/tools/perf/tests/builtin-test.c >> b/tools/perf/tests/builtin-test.c >> index 54ca7d87236f..e83c15a95c43 100644 >> --- a/tools/perf/tests/builtin-test.c >> +++

Re: [PATCH v2] perf test: S390 does not support watchpoints in test 22

On 09/28/2018 10:37 AM, Ravi Bangoria wrote: > Hi Thomas, > > On 09/28/2018 01:13 PM, Thomas Richter wrote: >> diff --git a/tools/perf/tests/builtin-test.c >> b/tools/perf/tests/builtin-test.c >> index 54ca7d87236f..e83c15a95c43 100644 >> --- a/tools/perf/tests/builtin-test.c >> +++

Re: [PATCH 77/77] perf tests: Fix record+probe_libc_inet_pton.sh without ping's debuginfo

On 09/06/2018 12:04 AM, Arnaldo Carvalho de Melo wrote: > rpm -e iputils-debuginfo I have done the same on my s390 this morning: [root@p23lp27 perf]# ./perf test ping 60: probe libc's inet_pton & backtrace it with ping : Ok [root@p23lp27 perf]# rpm -e iputils-debuginfo [root@p23lp27 perf]#

Re: [PATCH 77/77] perf tests: Fix record+probe_libc_inet_pton.sh without ping's debuginfo

On 09/06/2018 12:04 AM, Arnaldo Carvalho de Melo wrote: > rpm -e iputils-debuginfo I have done the same on my s390 this morning: [root@p23lp27 perf]# ./perf test ping 60: probe libc's inet_pton & backtrace it with ping : Ok [root@p23lp27 perf]# rpm -e iputils-debuginfo [root@p23lp27 perf]#

Re: [PATCH] perf annotate: Handle arm64 move instructions

On 08/27/2018 10:08 PM, Kim Phillips wrote: > Add default handler for non-jump instructions. This really only has an > effect on instructions that compute a PC-relative address, such as 'adrp,' > as seen in these couple of examples: > > BEFORE: adrp x0, 2aa11000 > AFTER: adrp x0,

Re: [PATCH] perf annotate: Handle arm64 move instructions

On 08/27/2018 10:08 PM, Kim Phillips wrote: > Add default handler for non-jump instructions. This really only has an > effect on instructions that compute a PC-relative address, such as 'adrp,' > as seen in these couple of examples: > > BEFORE: adrp x0, 2aa11000 > AFTER: adrp x0,

Re: [PATCH] perf annotate: fix parsing aarch64 branch instructions after objdump update

On 08/24/2018 02:10 AM, Kim Phillips wrote: > Starting with binutils 2.28, aarch64 objdump adds comments to the > disassembly output to show the alternative names of a condition code [1]. > > It is assumed that commas in objdump comments could occur in other arches > now or in the future, so this

Re: [PATCH] perf annotate: fix parsing aarch64 branch instructions after objdump update

On 08/24/2018 02:10 AM, Kim Phillips wrote: > Starting with binutils 2.28, aarch64 objdump adds comments to the > disassembly output to show the alternative names of a condition code [1]. > > It is assumed that commas in objdump comments could occur in other arches > now or in the future, so this

Re: [PATCH 2/3] perf report: Add raw report support for s390 auxiliary trace

On 08/08/2018 06:42 PM, Arnaldo Carvalho de Melo wrote: > Em Wed, Aug 08, 2018 at 01:14:51PM -0300, Arnaldo Carvalho de Melo escreveu: >> Em Wed, Aug 08, 2018 at 01:08:43PM -0300, Arnaldo Carvalho de Melo escreveu: >>> No need for __packed. >> >>> I'm removing that to avoid having this failling

Re: [PATCH 2/3] perf report: Add raw report support for s390 auxiliary trace

On 08/08/2018 06:42 PM, Arnaldo Carvalho de Melo wrote: > Em Wed, Aug 08, 2018 at 01:14:51PM -0300, Arnaldo Carvalho de Melo escreveu: >> Em Wed, Aug 08, 2018 at 01:08:43PM -0300, Arnaldo Carvalho de Melo escreveu: >>> No need for __packed. >> >>> I'm removing that to avoid having this failling

Re: [PATCH 2/3] perf report: Add raw report support for s390 auxiliary trace

On 08/08/2018 05:37 AM, m...@ellerman.id.au wrote: > Thomas Richter writes: >> Add support for s390 auxiliary trace support. >> Use 'perf record -e rbd000' to create the perf.data file. >> The event also has the symbolic name SF_CYCLES_BASIC_DIAG, >> using 'perf record -e SF_CYCLES_BASIC_DIAG' is

Re: [PATCH 2/3] perf report: Add raw report support for s390 auxiliary trace

On 08/08/2018 05:37 AM, m...@ellerman.id.au wrote: > Thomas Richter writes: >> Add support for s390 auxiliary trace support. >> Use 'perf record -e rbd000' to create the perf.data file. >> The event also has the symbolic name SF_CYCLES_BASIC_DIAG, >> using 'perf record -e SF_CYCLES_BASIC_DIAG' is

Re: BPF relocation 'perf test' entries failing was: Re: [GIT PULL 00/27] perf/core improvements and fixes

On 07/26/2018 09:14 PM, Arnaldo Carvalho de Melo wrote: > Em Thu, Jul 26, 2018 at 03:58:05PM -0300, Arnaldo Carvalho de Melo escreveu: >> Em Thu, Jul 26, 2018 at 11:04:08PM +0530, Sandipan Das escreveu: >>> I came across the same problem. Does the following patch fix it? > >>>

Re: BPF relocation 'perf test' entries failing was: Re: [GIT PULL 00/27] perf/core improvements and fixes

On 07/26/2018 09:14 PM, Arnaldo Carvalho de Melo wrote: > Em Thu, Jul 26, 2018 at 03:58:05PM -0300, Arnaldo Carvalho de Melo escreveu: >> Em Thu, Jul 26, 2018 at 11:04:08PM +0530, Sandipan Das escreveu: >>> I came across the same problem. Does the following patch fix it? > >>>

Re: [PATCH v2 1/4] perf test shell: Replace '|&' with '2>&1 |' to work with more shells

On 06/29/2018 07:46 PM, Kim Phillips wrote: > Since we do not specify bash (and/or zsh) as a requirement, use the > standard error redirection that is more widely supported. > > BEFORE: > > $ sudo ./perf test -v 62 > 62: Check open filename arg using perf trace + vfs_getname: > --- start ---

Re: [PATCH v2 1/4] perf test shell: Replace '|&' with '2>&1 |' to work with more shells

On 06/29/2018 07:46 PM, Kim Phillips wrote: > Since we do not specify bash (and/or zsh) as a requirement, use the > standard error redirection that is more widely supported. > > BEFORE: > > $ sudo ./perf test -v 62 > 62: Check open filename arg using perf trace + vfs_getname: > --- start ---

Re: [PATCH 4/4] perf stat: Add transaction flag (-T) support for s390

On 06/22/2018 04:36 AM, Andi Kleen wrote: > Thomas Richter writes: >> >> +/* Handle -T as -M transaction. Once platform specific metrics >> + * support has been added to the json files, all archiectures >> + * will use this approach. >> + */ >> +

Re: [PATCH 4/4] perf stat: Add transaction flag (-T) support for s390

On 06/22/2018 04:36 AM, Andi Kleen wrote: > Thomas Richter writes: >> >> +/* Handle -T as -M transaction. Once platform specific metrics >> + * support has been added to the json files, all archiectures >> + * will use this approach. >> + */ >> +

Re: [PATCH 2/2] perf test shell: make perf inet_pton test more portable

On 06/20/2018 01:49 AM, Kim Phillips wrote: > Debian based systems such as Ubuntu have dash as their default shell. > Even if the normal or root user's shell is bash, certain scripts still > call /bin/sh, which points to dash, so we fix this perf test by > rewriting it in a more portable way. > >

Re: [PATCH 2/2] perf test shell: make perf inet_pton test more portable

On 06/20/2018 01:49 AM, Kim Phillips wrote: > Debian based systems such as Ubuntu have dash as their default shell. > Even if the normal or root user's shell is bash, certain scripts still > call /bin/sh, which points to dash, so we fix this perf test by > rewriting it in a more portable way. > >

Re: [PATCH 2/3] perf alias: Rebuild alias expression string to make it comparable

On 06/15/2018 10:12 AM, Jiri Olsa wrote: > On Thu, Jun 14, 2018 at 08:53:14AM -0500, Paul Clarke wrote: > > SNIP > >>> + if (ret) >>> + ret += scnprintf(newval + ret, sizeof(newval) - ret, >>> +","); >>> + if

Re: [PATCH 2/3] perf alias: Rebuild alias expression string to make it comparable

On 06/15/2018 10:12 AM, Jiri Olsa wrote: > On Thu, Jun 14, 2018 at 08:53:14AM -0500, Paul Clarke wrote: > > SNIP > >>> + if (ret) >>> + ret += scnprintf(newval + ret, sizeof(newval) - ret, >>> +","); >>> + if

Re: [PATCH 3/3] perf stat: Remove duplicate event counting

On 06/15/2018 10:21 AM, Jiri Olsa wrote: > On Thu, Jun 14, 2018 at 01:48:45PM +0200, Thomas Richter wrote: > > SNIP > >> +static void perf_pmu_assign_str(char *name, const char *field, char >> **old_str, >> +char **new_str) >> +{ >> +if (!*old_str) >> +

Re: [PATCH 3/3] perf stat: Remove duplicate event counting

On 06/15/2018 10:21 AM, Jiri Olsa wrote: > On Thu, Jun 14, 2018 at 01:48:45PM +0200, Thomas Richter wrote: > > SNIP > >> +static void perf_pmu_assign_str(char *name, const char *field, char >> **old_str, >> +char **new_str) >> +{ >> +if (!*old_str) >> +

Re: [PATCH 2/3] perf alias: Rebuild alias expression string to make it comparable

On 06/14/2018 03:53 PM, Paul Clarke wrote: > On 06/14/2018 06:48 AM, Thomas Richter wrote: >> PMU alias definitions in sysfs files may have spaces, newlines >> and number with leading zeroes. Same alias definitions may >> also appear in JSON files without spaces, etc. >> >> Scan alias definitions

Re: [PATCH 2/3] perf alias: Rebuild alias expression string to make it comparable

On 06/14/2018 03:53 PM, Paul Clarke wrote: > On 06/14/2018 06:48 AM, Thomas Richter wrote: >> PMU alias definitions in sysfs files may have spaces, newlines >> and number with leading zeroes. Same alias definitions may >> also appear in JSON files without spaces, etc. >> >> Scan alias definitions

Re: [PATCH 1/3] perf alias: Remove trailing newline when reading sysfs files

On 06/14/2018 03:17 PM, Paul Clarke wrote: > On 06/14/2018 06:48 AM, Thomas Richter wrote: >> Remove a trailing newline when reading sysfs file contents >> such as /sys/devices/cpum_cf/events/TX_NC_TEND. >> This show when verbose option -v is used. >> >> Output before: >> tx_nc_tend ->

Re: [PATCH 1/3] perf alias: Remove trailing newline when reading sysfs files

On 06/14/2018 03:17 PM, Paul Clarke wrote: > On 06/14/2018 06:48 AM, Thomas Richter wrote: >> Remove a trailing newline when reading sysfs file contents >> such as /sys/devices/cpum_cf/events/TX_NC_TEND. >> This show when verbose option -v is used. >> >> Output before: >> tx_nc_tend ->

Re: [PATCH] perf test: Test 6 dumps core on s390

On 06/08/2018 04:53 PM, Kim Phillips wrote: > On Fri, 8 Jun 2018 15:17:28 +0200 > Thomas Richter wrote: > >> Perf test case 6 "Parse event definition strings" >> dumps core when executed on s390. > > I reported it actually fails on any $ARCH system without > Intel Processor Trace (PT) h/w: > >

Re: [PATCH] perf test: Test 6 dumps core on s390

On 06/08/2018 04:53 PM, Kim Phillips wrote: > On Fri, 8 Jun 2018 15:17:28 +0200 > Thomas Richter wrote: > >> Perf test case 6 "Parse event definition strings" >> dumps core when executed on s390. > > I reported it actually fails on any $ARCH system without > Intel Processor Trace (PT) h/w: > >

Re: regression: "95cde3c59966 debugfs: inode: debugfs_create_dir uses mode permission from parent" terminally annoys libvirt

On 06/08/2018 09:16 AM, Mike Galbraith wrote: > Greetings, > > $subject bisected and verified via revert. Box is garden variety > i4790, distro is openSUSE Leap 15.0. > > Error starting domain: internal error: process exited while connecting to > monitor: ioctl(KVM_CREATE_VM) failed: 12 Cannot

Re: regression: "95cde3c59966 debugfs: inode: debugfs_create_dir uses mode permission from parent" terminally annoys libvirt

On 06/08/2018 09:16 AM, Mike Galbraith wrote: > Greetings, > > $subject bisected and verified via revert. Box is garden variety > i4790, distro is openSUSE Leap 15.0. > > Error starting domain: internal error: process exited while connecting to > monitor: ioctl(KVM_CREATE_VM) failed: 12 Cannot

Re: [PATCH] perf docu: Update section on cpu topology

On 05/28/2018 09:54 PM, Arnaldo Carvalho de Melo wrote: > Em Mon, May 28, 2018 at 09:44:33AM +0200, Thomas Richter escreveu: >> Add an explanation of each cpu's core and socket >> identifier to the documentation. > > Thanks, applying. I guess it is not that worth to mention that older > files may

Re: [PATCH] perf docu: Update section on cpu topology

On 05/28/2018 09:54 PM, Arnaldo Carvalho de Melo wrote: > Em Mon, May 28, 2018 at 09:44:33AM +0200, Thomas Richter escreveu: >> Add an explanation of each cpu's core and socket >> identifier to the documentation. > > Thanks, applying. I guess it is not that worth to mention that older > files may

Re: [PATCH] perf test 39 (Session topology) dumps core on s390

On 05/28/2018 05:49 AM, Ravi Bangoria wrote: > Hi Thomas, > > On 05/24/2018 07:26 PM, Thomas Richter wrote: >> @@ -95,7 +98,7 @@ int test__session_topology(struct test *test >> __maybe_unused, int subtest __maybe >> { >> char path[PATH_MAX]; >> struct cpu_map *map; >> -int ret =

Re: [PATCH] perf test 39 (Session topology) dumps core on s390

On 05/28/2018 05:49 AM, Ravi Bangoria wrote: > Hi Thomas, > > On 05/24/2018 07:26 PM, Thomas Richter wrote: >> @@ -95,7 +98,7 @@ int test__session_topology(struct test *test >> __maybe_unused, int subtest __maybe >> { >> char path[PATH_MAX]; >> struct cpu_map *map; >> -int ret =

Re: [PATCH] perf tests: Fix regex for record+probe_libc_inet_pton.sh

On 05/18/2018 04:14 PM, Arnaldo Carvalho de Melo wrote: > Em Fri, May 18, 2018 at 01:09:48PM +0200, Thomas-Mich Richter escreveu: >> On 05/18/2018 12:29 PM, Sandipan Das wrote: >>> Can you please apply these two patches as well and then re-test? > >>> [1] https

Re: [PATCH] perf tests: Fix regex for record+probe_libc_inet_pton.sh

On 05/18/2018 04:14 PM, Arnaldo Carvalho de Melo wrote: > Em Fri, May 18, 2018 at 01:09:48PM +0200, Thomas-Mich Richter escreveu: >> On 05/18/2018 12:29 PM, Sandipan Das wrote: >>> Can you please apply these two patches as well and then re-test? > >>> [1] https

Re: [PATCH] perf tests: Fix regex for record+probe_libc_inet_pton.sh

On 05/18/2018 12:29 PM, Sandipan Das wrote: > Hi Thomas, > > On 05/18/2018 03:51 PM, Thomas-Mich Richter wrote: > [...] >> >> This patch fails on s390. I used 4.17.0rc5 + fedora 27 and I get this output: >> >> >> [root@p23lp27 perf]# ./perf test 59

Re: [PATCH] perf tests: Fix regex for record+probe_libc_inet_pton.sh

On 05/18/2018 12:29 PM, Sandipan Das wrote: > Hi Thomas, > > On 05/18/2018 03:51 PM, Thomas-Mich Richter wrote: > [...] >> >> This patch fails on s390. I used 4.17.0rc5 + fedora 27 and I get this output: >> >> >> [root@p23lp27 perf]# ./perf test 59

Re: [PATCH] perf tests: Fix regex for record+probe_libc_inet_pton.sh

On 05/18/2018 09:24 AM, Sandipan Das wrote: > This test currently fails because the regular expressions for > matching the output of perf script do not consider the symbol > offsets to be part of the output. > > The symbol offsets are seen because of the default behaviour > introduced by commit

Re: [PATCH] perf tests: Fix regex for record+probe_libc_inet_pton.sh

On 05/18/2018 09:24 AM, Sandipan Das wrote: > This test currently fails because the regular expressions for > matching the output of perf script do not consider the symbol > offsets to be part of the output. > > The symbol offsets are seen because of the default behaviour > introduced by commit

Re: [PATCH v3] module: Fix display of wrong module .text address

On 05/02/2018 04:20 AM, Kees Cook wrote: > On Wed, Apr 18, 2018 at 12:14 AM, Thomas Richter > wrote: >> Reading file /proc/modules shows the correct address: >> [root@s35lp76 ~]# cat /proc/modules | egrep '^qeth_l2' >> qeth_l2 94208 1 - Live 0x03ff80401000 >> >> and

Re: [PATCH v3] module: Fix display of wrong module .text address

On 05/02/2018 04:20 AM, Kees Cook wrote: > On Wed, Apr 18, 2018 at 12:14 AM, Thomas Richter > wrote: >> Reading file /proc/modules shows the correct address: >> [root@s35lp76 ~]# cat /proc/modules | egrep '^qeth_l2' >> qeth_l2 94208 1 - Live 0x03ff80401000 >> >> and reading file

Re: [PATCH v2] inode: debugfs_create_dir uses mode permission from parent

On 04/27/2018 04:58 PM, Kees Cook wrote: > On Fri, Apr 27, 2018 at 6:49 AM, Greg KH wrote: >> I'm going to add Kees and the kernel-hardning list here, as I'd like >> their opinions for the patch below. >> >> Kees, do you have any problems with this patch? I know you

Re: [PATCH v2] inode: debugfs_create_dir uses mode permission from parent

On 04/27/2018 04:58 PM, Kees Cook wrote: > On Fri, Apr 27, 2018 at 6:49 AM, Greg KH wrote: >> I'm going to add Kees and the kernel-hardning list here, as I'd like >> their opinions for the patch below. >> >> Kees, do you have any problems with this patch? I know you worked on >> making debugfs

Re: [PATCH] inode: debugfs_create_dir uses mode permission from parent

On 04/27/2018 12:06 PM, Greg KH wrote: > On Fri, Apr 27, 2018 at 11:14:26AM +0200, Thomas-Mich Richter wrote: >> On 04/27/2018 10:27 AM, Greg KH wrote: >>> On Fri, Apr 27, 2018 at 10:07:12AM +0200, Thomas Richter wrote: >>>> Currently function debugfs_create_dir(

Re: [PATCH] inode: debugfs_create_dir uses mode permission from parent

On 04/27/2018 12:06 PM, Greg KH wrote: > On Fri, Apr 27, 2018 at 11:14:26AM +0200, Thomas-Mich Richter wrote: >> On 04/27/2018 10:27 AM, Greg KH wrote: >>> On Fri, Apr 27, 2018 at 10:07:12AM +0200, Thomas Richter wrote: >>>> Currently function debugfs_create_dir(

Re: [PATCH] inode: debugfs_create_dir uses mode permission from parent

On 04/27/2018 10:27 AM, Greg KH wrote: > On Fri, Apr 27, 2018 at 10:07:12AM +0200, Thomas Richter wrote: >> Currently function debugfs_create_dir() creates a new >> directory in the debugfs (usually mounted /sys/kernel/debug) >> with permission rwxr-xr-x. This is hard coded. >> >> Change this to

Re: [PATCH] inode: debugfs_create_dir uses mode permission from parent

On 04/27/2018 10:27 AM, Greg KH wrote: > On Fri, Apr 27, 2018 at 10:07:12AM +0200, Thomas Richter wrote: >> Currently function debugfs_create_dir() creates a new >> directory in the debugfs (usually mounted /sys/kernel/debug) >> with permission rwxr-xr-x. This is hard coded. >> >> Change this to

Re: [PATCH] perf test: Adapt test case record+probe_libc_inet_pton.sh for s390

On 04/26/2018 05:26 PM, Martin Vuille wrote: > > > On 04/26/18 04:09, Thomas-Mich Richter wrote: >> was different. With you patch it changed from /usr/lib64/libc.so (old) to >> /usr/lib/debug/lib64/libc-2.26.so.debug (new) >> > Thomas, > > Can you tell me wha

Re: [PATCH] perf test: Adapt test case record+probe_libc_inet_pton.sh for s390

On 04/26/2018 05:26 PM, Martin Vuille wrote: > > > On 04/26/18 04:09, Thomas-Mich Richter wrote: >> was different. With you patch it changed from /usr/lib64/libc.so (old) to >> /usr/lib/debug/lib64/libc-2.26.so.debug (new) >> > Thomas, > > Can you tell me wha

Re: [PATCH] perf test: Adapt test case record+probe_libc_inet_pton.sh for s390

On 04/25/2018 04:19 PM, Martin Vuille wrote: > Apologies for any problems my patch may be causing. > > I'm unclear on what is the proposed fix, other than reverting the commit. > > In the problem scenario, is a --symfs option used? Is the debug info being > obtained from the symfs directory? >

Re: [PATCH] perf test: Adapt test case record+probe_libc_inet_pton.sh for s390

On 04/25/2018 04:19 PM, Martin Vuille wrote: > Apologies for any problems my patch may be causing. > > I'm unclear on what is the proposed fix, other than reverting the commit. > > In the problem scenario, is a --symfs option used? Is the debug info being > obtained from the symfs directory? >

Re: s390 perf events JSONs query

On 04/20/2018 12:51 PM, John Garry wrote: > Hi Hendrik, Thomas, > > I noticed that in 4.17-rc1 support was included for s390 perf pmu-events. I > also notice that the JSONs contain many common (identical actually) events > between different chips for this arch. > > Support was added for

Re: s390 perf events JSONs query

On 04/20/2018 12:51 PM, John Garry wrote: > Hi Hendrik, Thomas, > > I noticed that in 4.17-rc1 support was included for s390 perf pmu-events. I > also notice that the JSONs contain many common (identical actually) events > between different chips for this arch. > > Support was added for

Re: s390 perf events JSONs query

On 04/20/2018 12:51 PM, John Garry wrote: > Hi Hendrik, Thomas, > > I noticed that in 4.17-rc1 support was included for s390 perf pmu-events. I > also notice that the JSONs contain many common (identical actually) events > between different chips for this arch. > > Support was added for

Re: s390 perf events JSONs query

On 04/20/2018 12:51 PM, John Garry wrote: > Hi Hendrik, Thomas, > > I noticed that in 4.17-rc1 support was included for s390 perf pmu-events. I > also notice that the JSONs contain many common (identical actually) events > between different chips for this arch. > > Support was added for

Re: [PATCH v2] perf list: Add s390 support for detailed/verbose pmu event description

On 04/16/2018 04:43 PM, Mark Rutland wrote: > On Mon, Apr 16, 2018 at 03:23:14PM +0200, Thomas Richter wrote: >> From: Thomas Richter >> >> Perf list with flags -d and -v print a description (-d) or >> a very verbose explanation (-v) of CPU specific counter events. >>

Re: [PATCH v2] perf list: Add s390 support for detailed/verbose pmu event description

On 04/16/2018 04:43 PM, Mark Rutland wrote: > On Mon, Apr 16, 2018 at 03:23:14PM +0200, Thomas Richter wrote: >> From: Thomas Richter >> >> Perf list with flags -d and -v print a description (-d) or >> a very verbose explanation (-v) of CPU specific counter events. >> These descriptions are

Re: [PATCH v3] module: Fix display of wrong module .text address

On 04/18/2018 09:17 AM, Tobin C. Harding wrote: > On Wed, Apr 18, 2018 at 09:14:36AM +0200, Thomas Richter wrote: >> Reading file /proc/modules shows the correct address: >> [root@s35lp76 ~]# cat /proc/modules | egrep '^qeth_l2' >> qeth_l2 94208 1 - Live 0x03ff80401000 >> >> and reading file

Re: [PATCH v3] module: Fix display of wrong module .text address

On 04/18/2018 09:17 AM, Tobin C. Harding wrote: > On Wed, Apr 18, 2018 at 09:14:36AM +0200, Thomas Richter wrote: >> Reading file /proc/modules shows the correct address: >> [root@s35lp76 ~]# cat /proc/modules | egrep '^qeth_l2' >> qeth_l2 94208 1 - Live 0x03ff80401000 >> >> and reading file

Re: Wrong module .text address in 4.16.0

On 04/16/2018 08:23 AM, Christian Borntraeger wrote: > FWIW, this breaks at least perf capability to resolve module symbols. > Adding some more CCs for perf and module. > > > On 04/16/2018 07:51 AM, Thomas-Mich Richter wrote: >> I just installed 4.16.0 and discovered the

Re: Wrong module .text address in 4.16.0

On 04/16/2018 08:23 AM, Christian Borntraeger wrote: > FWIW, this breaks at least perf capability to resolve module symbols. > Adding some more CCs for perf and module. > > > On 04/16/2018 07:51 AM, Thomas-Mich Richter wrote: >> I just installed 4.16.0 and discovered the

Wrong module .text address in 4.16.0

I just installed 4.16.0 and discovered the module .text address is wrong. It happens on s390 and x86 platforms. I have not tested others. Here is the issue, I have used module qeth_l2 on s390 which is the ethernet device driver: root@s35lp76 ~]# lsmod Module Size Used by

Wrong module .text address in 4.16.0

I just installed 4.16.0 and discovered the module .text address is wrong. It happens on s390 and x86 platforms. I have not tested others. Here is the issue, I have used module qeth_l2 on s390 which is the ethernet device driver: root@s35lp76 ~]# lsmod Module Size Used by

Re: [PATCH] perf record: Remove unnecessary warning for missing sysfs entry

On 04/12/2018 03:05 PM, Arnaldo Carvalho de Melo wrote: > Em Thu, Apr 12, 2018 at 01:47:23PM +0200, Thomas Richter escreveu: >> Using perf on 4.16.0 kernel on s390 shows warning >>failed: can't open node sysfs data >> each time I run command perf record ... for example: >> >> [root@s35lp76

Re: [PATCH] perf record: Remove unnecessary warning for missing sysfs entry

On 04/12/2018 03:05 PM, Arnaldo Carvalho de Melo wrote: > Em Thu, Apr 12, 2018 at 01:47:23PM +0200, Thomas Richter escreveu: >> Using perf on 4.16.0 kernel on s390 shows warning >>failed: can't open node sysfs data >> each time I run command perf record ... for example: >> >> [root@s35lp76

Re: [PATCH] perf list: Add s390 support for detailed/verbose pmu event description

On 04/09/2018 04:18 PM, Mark Rutland wrote: > On Mon, Apr 09, 2018 at 03:03:32PM +0200, Thomas-Mich Richter wrote: >> On 04/09/2018 01:37 PM, Mark Rutland wrote: >>> On Mon, Apr 09, 2018 at 01:00:15PM +0200, Thomas Richter wrote: >>>> @@ -562,6 +562,12 @@ static in

Re: [PATCH] perf list: Add s390 support for detailed/verbose pmu event description

On 04/09/2018 04:18 PM, Mark Rutland wrote: > On Mon, Apr 09, 2018 at 03:03:32PM +0200, Thomas-Mich Richter wrote: >> On 04/09/2018 01:37 PM, Mark Rutland wrote: >>> On Mon, Apr 09, 2018 at 01:00:15PM +0200, Thomas Richter wrote: >>>> @@ -562,6 +562,12 @@ static in

Re: [PATCH] perf list: Add s390 support for detailed/verbose pmu event description

On 04/09/2018 01:37 PM, Mark Rutland wrote: > Hi, > > On Mon, Apr 09, 2018 at 01:00:15PM +0200, Thomas Richter wrote: >> From: Thomas Richter >> >> Perf list with flags -d and -v print a description (-d) or >> a very verbose explanation (-v) of CPU specific counter

Re: [PATCH] perf list: Add s390 support for detailed/verbose pmu event description

On 04/09/2018 01:37 PM, Mark Rutland wrote: > Hi, > > On Mon, Apr 09, 2018 at 01:00:15PM +0200, Thomas Richter wrote: >> From: Thomas Richter >> >> Perf list with flags -d and -v print a description (-d) or >> a very verbose explanation (-v) of CPU specific counter events. >> These descriptions

Re: [PATCH] perf stat: Add support for s390 transaction counters

On 03/14/2018 02:18 PM, Arnaldo Carvalho de Melo wrote: > Em Wed, Mar 14, 2018 at 09:34:48AM +0100, Thomas-Mich Richter escreveu: >> On 03/13/2018 04:23 AM, Andi Kleen wrote: >>> Thomas Richter <tmri...@linux.vnet.ibm.com> writes: > >>>> Right now t

Re: [PATCH] perf stat: Add support for s390 transaction counters

On 03/14/2018 02:18 PM, Arnaldo Carvalho de Melo wrote: > Em Wed, Mar 14, 2018 at 09:34:48AM +0100, Thomas-Mich Richter escreveu: >> On 03/13/2018 04:23 AM, Andi Kleen wrote: >>> Thomas Richter writes: > >>>> Right now there is only hard coded suppor

Re: [PATCH] perf stat: Add support for s390 transaction counters

On 03/13/2018 04:23 AM, Andi Kleen wrote: > Thomas Richter writes: > >> Right now there is only hard coded support for x86. > > That's not true. There is support for generic transaction events in perf. > > As far as I can tell your events would map 1:1 to the

Re: [PATCH] perf stat: Add support for s390 transaction counters

On 03/13/2018 04:23 AM, Andi Kleen wrote: > Thomas Richter writes: > >> Right now there is only hard coded support for x86. > > That's not true. There is support for generic transaction events in perf. > > As far as I can tell your events would map 1:1 to the generic tx-* events. > > -Andi >

Re: [PATCH Resent] perf annotate: Fix s390 target function disassembly

On 03/06/2018 03:04 PM, Arnaldo Carvalho de Melo wrote: > Em Tue, Mar 06, 2018 at 01:39:55PM +0100, Thomas Richter escreveu: >> Perf annotate displays function call assembler instructions >> with a right arrow. Hitting enter on this line/instruction >> causes the browser to disassemble this target

Re: [PATCH Resent] perf annotate: Fix s390 target function disassembly

On 03/06/2018 03:04 PM, Arnaldo Carvalho de Melo wrote: > Em Tue, Mar 06, 2018 at 01:39:55PM +0100, Thomas Richter escreveu: >> Perf annotate displays function call assembler instructions >> with a right arrow. Hitting enter on this line/instruction >> causes the browser to disassemble this target

Re: [RFC 0/5] per-event settings fixes

On 01/16/2018 03:24 PM, Arnaldo Carvalho de Melo wrote: > From: Arnaldo Carvalho de Melo > > Hi guys, > > Jiri asked me to post this series, so here it is, please take a > look, I'd love to harvest your Reviewed-by/Tested-by/Acked-by, > > - Arnaldo > > Arnaldo Carvalho

  1   2   >