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()
>> hist_iter__report_c
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:
>>
.
>>
>&
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, hea
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!!!
>>>
>>>
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!!!
>>>
>>>
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/
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
>>
>> __schedule()
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
>>
>> __schedule()
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
>>
>> __schedule()
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
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
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 me
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 +25
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 nu
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 t
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 counters
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 drivers/cpufreq/in
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
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
>> +++ b/tools/perf/
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]#
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, ka
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
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 i
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
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?
>
>>> https://lkml.org/lkm
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 ---
>
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.
>> + */
>> +
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.
>
>
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 (term->type_va
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)
>> +
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 a
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 -> 'cpum_cf'/'e
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:
>
>
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
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
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 = -1
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
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
&g
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 41
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 /sys/module/q
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 mo
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() c
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 us
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
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?
>
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 factori
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 factori
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 provid
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 /s
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 mo
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
qeth_l2
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 perf
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
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 a
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 support for x86.
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
>
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
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 de Melo (5):
> p
On 01/15/2018 03:16 PM, Arnaldo Carvalho de Melo wrote:
> Em Mon, Jan 15, 2018 at 10:57:52AM -0300, Arnaldo Carvalho de Melo escreveu:
>>> [root@f27 perf]# ./perf trace --no-syscalls --max-stack 4
>>> -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
>>> PING ::1(::1) 56 data bytes
On 01/12/2018 09:02 PM, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jan 12, 2018 at 01:47:06PM -0300, Arnaldo Carvalho de Melo escreveu:
>> There is still room for improvement, I noticed overriding is not working
>> for the probe event, investigating it now.
>
> So, I had to fix this another way to
On 01/12/2018 09:02 PM, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jan 12, 2018 at 01:47:06PM -0300, Arnaldo Carvalho de Melo escreveu:
>> There is still room for improvement, I noticed overriding is not working
>> for the probe event, investigating it now.
>
> So, I had to fix this another way to
On 12/18/2017 07:16 PM, Linus Torvalds wrote:
> On Mon, Dec 18, 2017 at 9:59 AM, Steven Rostedt wrote:
>>
>> Hmm, since the scrambling of %p is to prevent kernel addresses from
>> leaking, I wonder if it would be OK to make it only scramble the address
>> if the address is a kernel address. It sho
On 12/15/2017 03:21 PM, Peter Zijlstra wrote:
> On Fri, Dec 15, 2017 at 03:14:37PM +0100, Thomas-Mich Richter wrote:
>> During debugging of perf probe tool I discovered an issue with
>> uprobes and address randomization.
>>
>> To set a uprobe on a function named ine
During debugging of perf probe tool I discovered an issue with
uprobes and address randomization.
To set a uprobe on a function named inet_pton in libc library, you
obtain the address of the symbol inet_pton using command nm and
then use the following command to set the uprobe:
# echo "p:probe_li
On 12/13/2017 05:31 PM, Arnaldo Carvalho de Melo wrote:
> Hi, noticed this with my perf/core branch, will investigate later.
>
> [root@jouet ubuntu]# cat /tmp/dm.log.JAK3XV/ubuntu\:16.04-x-s390
> ubuntu:16.04-x-s390
> Downloading http://192.168.124.1/perf/perf-4.15.0-rc3.tar.xz...
> % Total
On 12/12/2017 06:12 PM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Dec 12, 2017 at 05:24:43PM +0100, Michael Petlan escreveu:
>> Hey Arnaldo, this one did not remove the s390x hack and also, won't work
>> on arm. Please use the one I just have sent, few seconds ago...
>
> Ok, I have you latest in,
On 12/07/2017 08:19 AM, Masami Hiramatsu wrote:
> Hi,
>
> Here is the 2nd version of the series for probing on
> versioned symbols in libraries. This includes 5 patches
> to fix the issues discussed on perf-users ML
> (https://www.spinics.net/lists/linux-perf-users/msg04637.html)
>
> The first v
On 12/07/2017 08:21 AM, Masami Hiramatsu wrote:
> Support the special characters escaped by '\' in parser.
> This allows user to specify versions directly like below.
>
> =
> # ./perf probe -x /lib64/libc-2.25.so malloc_get_state\\@GLIBC_2.2.5
> Added new event:
> probe_libc:malloc_g
On 12/07/2017 08:21 AM, Masami Hiramatsu wrote:
> Find versioned symbols correctly from map.
> Commit d80406453ad4 ("perf symbols: Allow user probes on
> versioned symbols") allows user to find default versioned
> symbols (with "@@") in map. However, it did not enable
> normal versioned symbol (wit
On 11/29/2017 02:24 PM, Ravi Bangoria wrote:
>
>
> On 11/28/2017 01:26 PM, Thomas Richter wrote:
>> The command 'perf annotate' parses the output of objdump and also
>> investigates the comments produced by objdump. For example the
>> output of objdump produces (on x86):
>>
>> 23eee: 4c 8b 3d 13
On 11/28/2017 03:50 PM, Arnaldo Carvalho de Melo wrote:
.
>>
>> 60b4: 48 8b 05 35 cd 22 00mov 0x22cd35(%rip),%rax # 232df0
>> <__gmon_start__>
>>
>> Commit 6de783b6f50f7f1db18a3fda0aa34b2e84b5771d ("perf annotate: Resolve
>> symbols
>> using objdump comment") added t
On 11/14/2017 02:47 PM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Nov 14, 2017 at 10:34:09AM -0300, Arnaldo Carvalho de Melo escreveu:
>>> Different name, same contents, need to look at the inode... ;-\
>>
>> Nah, lets ask the kernel how is it that it sees libc, please test the
>> following, works
On 08/15/2017 05:25 PM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Aug 15, 2017 at 11:21:59AM +0200, Thomas Richter escreveu:
>
> Ok, I'm applying this, the only missing bit was the following line,
> right at the start of the patch message body;
>
> From: Wang Nan
>
> To state that the patch was
On 08/14/2017 06:39 PM, Arnaldo Carvalho de Melo wrote:
> Em Mon, Aug 14, 2017 at 01:46:44PM +0200, Thomas Richter escreveu:
>> Perf BPF prologue generator unconditionally fetches 8 bytes for function
>> parameters, which causes problem on big endian machine. Thomas gives a
>> detail analysis for t
On 08/14/2017 12:30 PM, Wangnan (F) wrote:
> Hi Thomas,
>
> Your patch looks good to me. I've tested in my environment and it works.
> Please resend it to lkml and let Arnaldo to collect it.
>
> Thank you.
>
Will do, I take this as an Acked-by and Tested-by, ok?
Thanks
--
Thomas Richter, Dept
On 08/11/2017 09:23 PM, Arnaldo Carvalho de Melo wrote:
> Em Fri, Aug 11, 2017 at 06:47:56PM +0800, Wangnan (F) escreveu:
>> Hi Thomas,
>>
>> Please try this patch on your machine and give me the result.
>
> Right, I'm waiting for test results for the last two patches from Wang:
>
> (3.0K)
On 08/11/2017 11:57 AM, Wangnan (F) wrote:
>
>
> On 2017/8/11 17:17, Thomas-Mich Richter wrote:
>> On 08/11/2017 07:19 AM, Wangnan (F) wrote:
[]
> Your analysis is correct.
>
>>
>> Maybe the solution is to add an endianness convertion into the gen_read_m
On 08/11/2017 07:19 AM, Wangnan (F) wrote:
>
>
> On 2017/8/11 2:13, Arnaldo Carvalho de Melo wrote:
>> Thomas, please try to find who wrote that test and CC him, I'm doing it
>> this time, Wang, can you please take a look at this?
>>
>> I also added lkml to the CC list, here we have more users o
On 08/11/2017 07:19 AM, Wangnan (F) wrote:
>
>
> On 2017/8/11 2:13, Arnaldo Carvalho de Melo wrote:
>> Thomas, please try to find who wrote that test and CC him, I'm doing it
>> this time, Wang, can you please take a look at this?
>>
>> I also added lkml to the CC list, here we have more users of
On 08/04/2017 05:28 PM, Daniel Borkmann wrote:
> From: Thomas-Mich Richter
> Date: Wed, Aug 2, 2017 at 1:22 AM
> [...]
>> I work on the perf tool and its bpf support for IBM s390 and came across a
>> strange issue compiling tools/testing/selftests/bpf/test_verifier.c on s39
I work on the perf tool and its bpf support for IBM s390 and came across a
strange issue compiling tools/testing/selftests/bpf/test_verifier.c on s390x.
This is the compile error:
gcc -Wall -O2 -I../../../include/uapi -I../../../lib
-I../../../../include/generated
-DHAVE_GENHDR -I../../../incl
On 07/11/2017 09:48 PM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jul 11, 2017 at 04:38:28PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Tue, Jul 11, 2017 at 04:03:04PM -0300, Arnaldo Carvalho de Melo escreveu:
>>> Em Fri, Jul 07, 2017 at 02:17:25PM +0200, Thomas-Mic
On 07/07/2017 09:36 PM, Krister Johansen wrote:
> On Thu, Jul 06, 2017 at 04:41:30PM -0300, Arnaldo Carvalho de Melo wrote:
>> Em Wed, Jul 05, 2017 at 06:48:08PM -0700, Krister Johansen escreveu:
>>> Teach perf how to resolve symbols from binaries that are in a different
>>> mount namespace from th
On 06/02/2017 04:11 PM, Arnaldo Carvalho de Melo wrote:
[]
>>
>> If you have specific patches in Jiri's branch that you think are good to
>> go, just point me to them and I'll cherry-pick them.
>>
>> I'm looking now at the one you pointed out above (070b9644981e).
>
> Just looked, but the cs
On 06/01/2017 11:04 PM, Jiri Olsa wrote:
> On Thu, Jun 01, 2017 at 10:20:38AM -0300, Arnaldo Carvalho de Melo wrote:
>> Em Thu, Jun 01, 2017 at 02:34:41PM +0200, Thomas Richter escreveu:
>>> Command perf test -v 14 (Setup struct perf_event_attr test)
>>> always reports success even if the test case
85 matches
Mail list logo
