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
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