[reply all this time...]
On 21 March 2017 at 17:21, Mathieu Poirier mathieu.poirier@linaro.org wrote:
On 21 March 2017 at 05:00, Mike Leach mike.leach@linaro.org wrote:
On 17 March 2017 at 14:28, Mathieu Poirier mathieu.poirier@linaro.org wrote:
On 17 March 2017 at 05:57, Mike Leach mike.leach@linaro.org wrote:
I can confirm this applies and runs OK on my juno-r1 system - linaro gcc6.2 built perf and kernel. (with no hard hang) I am also seeing the additional printout when I do perf report --dump
on
the collected data.
Perfect - thanks for the confirmation. I'll push to gitHub.
I can also confirm the issue Kim sees when using the 'sudo ./perf
record
-e cs_etm// uname ' command line.
A sink needs to be specified within the //. Otherwise perf doesn't know what sink to use.
Agreed. A re-test shows that if a sink is enabled using sysfs before
'sudo
./perf record -e cs_etm// uname' , then data is captured and no crash occurs. This
matches
what the coresight.txt documentation states, though re-enabling this way
is
required before each run
- a patch to the docs has been submitted to make this clear - along with
the option of defining the sink in the perf command line.
Without pre-enabling, missing the sink between cs_etm// causes the crash. Ideally, bad input should result in an error message. Something worth looking at in future?
When writing the driver I (mistakenly) thought the error message you get from perf was enough. To fix this we need to enhance the flex/bison infrastructure. If you guys think it's absolutely needed I can have a look but I'm pretty sure we can live with it.
On the flip side that part will need a huge overhaul when we add support for the multiple sink - I suggest we tackle it then.
Mathieu
Agreed, No rush to fix this immediately as not preventing people from
using it. Mike
Mike
Mike
On 16 March 2017 at 22:33, Kim Phillips kim.phillips@arm.com wrote:
On Thu, 16 Mar 2017 12:04:33 -0600 Mathieu Poirier mathieu.poirier@linaro.org wrote:
Reported-by: Kim Phillips kim.phillips@arm.com Signed-off-by: Mathieu Poirier mathieu.poirier@linaro.org
I wish I'd be able to add my Tested-by:, but unfortunately, I can't:
When I build perf natively with gcc 6.3, with this patch:
kim@juno perf perf-opencsd-4.11-rc1$ strings -a ./perf | grep GCC | head -1 GCC: (Debian 6.3.0-6) 6.3.0 20170205
and invoke perf slightly differently than in the other thread (no tasksets, no etr spec), I get the memory allocation failure:
kim@juno perf perf-opencsd-4.11-rc1$ sudo ./perf record -e cs_etm// uname failed to mmap with 12 (Cannot allocate memory) kim@juno perf perf-opencsd-4.11-rc1$ uname -a Linux juno 4.11.0-rc1-g8e9e2e2 #4 SMP PREEMPT Thu Mar 16 15:55:24 CDT 2017 aarch64 GNU/Linux kim@juno perf perf-opencsd-4.11-rc1$ dmesg |grep gcc [ 0.000000] Linux version 4.11.0-rc1-g8e9e2e2 (kim@dupont) (gcc version 4.9.4 20151028 (prerelease) (Linaro GCC 4.9-2016.02) ) #4 SMP PREEMPT Thu Mar 16 15:55:24 CDT 2017
but this time, there is a stacktrace on the serial console:
[ 119.044143] ------------[ cut here ]------------ [ 119.048729] WARNING: CPU: 0 PID: 2819 at
../kernel/workqueue.c:1442
__queue_work+0x3c8/0x478 [ 119.057080] Modules linked in: [ 119.060100] [ 119.061574] CPU: 0 PID: 2819 Comm: perf Not tainted 4.11.0-rc1-g8e9e2e2 #4 [ 119.068376] Hardware name: ARM Juno development board (r2) (DT) [ 119.074232] task: ffff8009732f0c80 task.stack: ffff80097612c000 [ 119.080090] PC is at __queue_work+0x3c8/0x478 [ 119.084400] LR is at __queue_work+0x29c/0x478 [ 119.088709] pc : [<ffff0000080e60c4>] lr : [<ffff0000080e5f98>] pstate: a00001c5 [ 119.096026] sp : ffff80097612fac0 [ 119.099302] x29: ffff80097612fac0 x28: 0000000000000000 [ 119.104560] x27: 0000000000000400 x26: ffff000009157740 [ 119.109818] x25: 0000000000000000 x24: ffff800976804400 [ 119.115075] x23: 0000000000000040 x22: ffff80097fea8280 [ 119.120333] x21: ffff000008fb4000 x20: ffff80097152ad80 [ 119.125591] x19: ffff80097feac100 x18: 0000000000000000 [ 119.130849] x17: 0000ffff7994a7a8 x16: ffff0000080894e0 [ 119.136106] x15: 000000000000013b x14: 0000000000000000 [ 119.141364] x13: 626b5f6b636f6c6d x12: 0000000000000000 [ 119.146621] x11: 0000000000000000 x10: 0000000000000000 [ 119.151879] x9 : 0000000000000000 x8 : ffff80097152ab80 [ 119.157136] x7 : 0000000000000000 x6 : 0000000000000001 [ 119.162393] x5 : 0000000000000000 x4 : 0000000000000000 [ 119.167650] x3 : 0000000000000000 x2 : 0000000000000000 [ 119.172907] x1 : 0000000000000000 x0 : ffff80097152ad88 [ 119.178164] [ 119.179634] ---[ end trace c565de4a9bd0da95 ]--- [ 119.184199] Call trace: [ 119.186618] Exception stack(0xffff80097612f8f0 to 0xffff80097612fa20) [ 119.192991] f8e0:
ffff80097feac100
0001000000000000 [ 119.200742] f900: ffff80097612fac0 ffff0000080e60c4
ffff80097612f930
ffff0000081c19e8 [ 119.208492] f920: ffff000009134a80 0000000000000000
ffff80097612fa20
ffff0000081c2370 [ 119.216242] f940: 0000000000000000 ffff000009135780
0000000000000001
0000000000000000 [ 119.223992] f960: ffff800972500000 0000000000000020
0000000000000000
00000000014092c0 [ 119.231742] f980: ffff800972506000 ffff7e0025c5de00
ffff80097152ad88
0000000000000000 [ 119.239491] f9a0: 0000000000000000 0000000000000000
0000000000000000
0000000000000000 [ 119.247241] f9c0: 0000000000000001 0000000000000000
ffff80097152ab80
0000000000000000 [ 119.254991] f9e0: 0000000000000000 0000000000000000
0000000000000000
626b5f6b636f6c6d [ 119.262741] fa00: 0000000000000000 000000000000013b
ffff0000080894e0
0000ffff7994a7a8 [ 119.270490] [<ffff0000080e60c4>] __queue_work+0x3c8/0x478 [ 119.275833] [<ffff0000080e61c4>] queue_work_on+0x50/0x6c [ 119.281092] [<ffff0000088d76b4>] etm_setup_aux+0x168/0x208 [ 119.286523] [<ffff0000081b30b0>] rb_alloc_aux+0x230/0x2b4 [ 119.291866] [<ffff0000081ae418>] perf_mmap+0x408/0x558 [ 119.296952] [<ffff0000081fc5f8>] mmap_region+0x340/0x55c [ 119.302209] [<ffff0000081fcb00>] do_mmap+0x2ec/0x394 [ 119.307122] [<ffff0000081dcce4>] vm_mmap_pgoff+0xcc/0xf0 [ 119.312379] [<ffff0000081fa53c>] SyS_mmap_pgoff+0xb0/0x23c [ 119.317809] [<ffff000008089538>] sys_mmap+0x58/0x74 [ 119.322636] [<ffff000008083730>] el0_svc_naked+0x24/0x28
It's 100% consistent. I don't expect this to be expected behaviour, esp. given the same way of invocation is in Documentation/trace/coresight.txt:
The Coresight PMUs can be configured to work in "full trace" or "snapshot" mode. In full trace mode trace acquisition is enabled from beginning to end with trace data being recorded continuously:
linaro@linaro-nano:~$ perf record -e cs_etm// dd if=/dev/random of=./test.txt bs=1k count=1000
Resolving the stack address from the etm_setup_aux entry in the stack trace:
kim@dupont juno perf-opencsd-4.11-rc1$ addr2line -e vmlinux ffff0000088d76b4
/home/kim/git/OpenCSD/juno/../drivers/hwtracing/coresight/
coresight-etm-perf.c:260
Line 260 is the closing '}' to the function. I'm not sure whether
that
means it's the INIT_WORK in the function that's not happy with something it was passed?
Looking at kernel/workqueue.c line 1442, it has:
if (WARN_ON(!list_empty(&work->entry))) {So perhaps one of INIT_WORK's params was NULL? Can you take a look?
btw, thanks for applying Sebastian's 'perf tools: fix printing of auxtrace_info': now, when using the invocation style mentioned in the other thread with Mike Leach (tasksets & etr spec), it makes perf 'finish its sentence' prior to locking up the system:
kim@juno perf perf-opencsd-4.11-rc1$ sudo ./perf record -e cs_etm/@20070000.etr/u --per-thread taskset -c 0 uname Linux [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.021 MB perf.data ]
<hang>
Thanks,
Kim _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- Mike Leach Principal Engineer, ARM Ltd. Blackburn Design Centre. UK
-- Mike Leach Principal Engineer, ARM Ltd. Blackburn Design Centre. UK