On 24 March 2017 at 00:44, Kim Phillips kim.phillips@arm.com wrote:
On Tue, 21 Mar 2017 21:44:14 +0000 Mike Leach mike.leach@linaro.org wrote:
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:
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.
Agreed, No rush to fix this immediately as not preventing people from using it.
depends on how one defines "using it": I tried to use it, and couldn't. I can now because I wrote this mailing list, and that's because I became impatient trying to debug the driver.
Just in preparing output for that last email I just sent, fully knowing that the step to enable the sink is necessary, I *still* hit up-arrow, enter, and got my terminal rudely splattered over:
Don't enable the sink using sysfs, specify the sink on the perf command line and use the up arrow as much as you like.
Mike
root@juno:~# taskset -c 2 /home/kim/git/OpenCSD/tools/perf/perf record -o perf-etm.data -e cs_etm//u --per-thread taskset -c 2 ./sort-O3 [ 1132.149525] ------------[ cut here ]------------ [ 1132.154109] WARNING: CPU: 2 PID: 2592 at ../kernel/workqueue.c:1442 __queue_work+0x450/0x520 [ 1132.162457] Modules linked in: ip_tables x_tables ipv6 [ 1132.167547] [ 1132.169018] CPU: 2 PID: 2592 Comm: perf Not tainted 4.11.0-rc3-00035-g093b995 #25 [ 1132.176421] Hardware name: ARM Juno development board (r2) (DT) [ 1132.182276] task: ffff800974e23400 task.stack: ffff800975528000 [ 1132.188132] PC is at __queue_work+0x450/0x520 [ 1132.192439] LR is at __queue_work+0x10c/0x520 [ 1132.196745] pc : [<ffff0000080e8958>] lr : [<ffff0000080e8614>] pstate: a00001c5 [ 1132.204062] sp : ffff80097552ba80 [ 1132.207335] x29: ffff80097552ba80 x28: ffff80097fea8300 [ 1132.212591] x27: ffff800970569400 x26: ffff000009059000 [ 1132.217847] x25: ffff0000091e0840 x24: 0000000000000002 [ 1132.223103] x23: 0000000000000040 x22: ffff800977404400 [ 1132.228358] x21: 0000000000000029 x20: ffff000009007000 [ 1132.233612] x19: ffff80097fedc100 x18: 0000000000000000 [ 1132.238868] x17: 0000ffffb66457a8 x16: ffff000008089668 [ 1132.244123] x15: 000000000000013b x14: 0000000000000000 [ 1132.249377] x13: 626b5f6b636f6c6d x12: 0000000000000040 [ 1132.254632] x11: 0000000000000005 x10: 0000000000000000 [ 1132.259888] x9 : ffff800977000028 x8 : 0000000000000000 [ 1132.265142] x7 : ffff80097fea8300 x6 : ffff80097fea8300 [ 1132.270398] x5 : ffff800977000000 x4 : ffff80097fea8300 [ 1132.275652] x3 : 0000000000000000 x2 : 0000000000000000 [ 1132.280907] x1 : 0000000000000000 x0 : ffff800970569408 [ 1132.286162] [ 1132.287630] ---[ end trace 52e5d735196c6a0d ]--- [ 1132.292194] Call trace: [ 1132.294609] Exception stack(0xffff80097552b8b0 to 0xffff80097552b9e0) [ 1132.300980] b8a0: ffff80097fedc100 0001000000000000 [ 1132.308727] b8c0: ffff80097552ba80 ffff0000080e8958 ffff80097fedcaf0 0000000000000000 [ 1132.316474] b8e0: ffff80097fedcaf0 0000000000000000 ffff80097552b920 ffff0000081d6e64 [ 1132.324221] b900: ffff80097552b920 ffff0000081d6afc ffff80097fff1c80 0000000000000011 [ 1132.331968] b920: ffff80097552ba10 ffff0000081d7594 0000000000000000 ffff80097fff2b80 [ 1132.339715] b940: 0000000000000001 0000000000000400 ffff800970569408 0000000000000000 [ 1132.347461] b960: 0000000000000000 0000000000000000 ffff80097fea8300 ffff800977000000 [ 1132.355208] b980: ffff80097fea8300 ffff80097fea8300 0000000000000000 ffff800977000028 [ 1132.362955] b9a0: 0000000000000000 0000000000000005 0000000000000040 626b5f6b636f6c6d [ 1132.370702] b9c0: 0000000000000000 000000000000013b ffff000008089668 0000ffffb66457a8 [ 1132.378449] [<ffff0000080e8958>] __queue_work+0x450/0x520 [ 1132.383789] [<ffff0000080e8a90>] queue_work_on+0x68/0x80 [ 1132.389045] [<ffff0000088f9044>] etm_setup_aux+0x164/0x228 [ 1132.394472] [<ffff0000081c63a8>] rb_alloc_aux+0x230/0x310 [ 1132.399811] [<ffff0000081c1520>] perf_mmap+0x3f8/0x560 [ 1132.404893] [<ffff000008213acc>] mmap_region+0x39c/0x5c8 [ 1132.410146] [<ffff000008213f4c>] do_mmap+0x254/0x380 [ 1132.415056] [<ffff0000081f2ab4>] vm_mmap_pgoff+0xcc/0xf0 [ 1132.420310] [<ffff000008211870>] SyS_mmap_pgoff+0xb0/0x230 [ 1132.425737] [<ffff0000080896c0>] sys_mmap+0x58/0x78 [ 1132.430561] [<ffff000008083730>] el0_svc_naked+0x24/0x28 failed to mmap with 12 (Cannot allocate memory) root@juno:~#
It seems to me a quick fix in the driver (not the flex/bison infrastructure) to emit a simple "I don't see a sink I can use" to dmesg and return an -EINVAL or somesuch would be much more user friendly than the above.
Just my 2c.
Kim