On Tue, 14 Mar 2017 13:10:43 +0000 Mike Leach mike.leach@linaro.org wrote:
On 14 March 2017 at 02:40, Kim Phillips kim.phillips@arm.com wrote:
$ ./perf --version perf version 4.11.rc1.ga5e89a5 $ git log --oneline -2 #perf needed the one patch at the bottom of this
a5e89a55d8b8 perf tool: cs-etm: fix build error by removing unused
cs_etm_global_header_fmts array
c50837387458 perf: cs-etm: Add decoder reset to stub
No sure why you need the added patch here - I can build without it from the opencsd-perf-4.11-rc1 branch.
I'm running Ubuntu 16.10, which provides aarch64-linux-gnu-gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005. I build perf like this:
cd tools make clean # cleans perf along with other tools dependencies make -C perf NO_JVMTI=1 DEBUG=5 ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
The NO_JVMTI=1 is there because the linker complains when building libperf-jvmti.so with "ld: cannot find -lelf". Toggling DEBUG does not change the behaviour, and:
make -C perf ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu
still results in:
util/cs-etm.c:1466:27: error: ‘cs_etm_global_header_fmts’ defined but not used [-Werror=unused-const-variable=] static const char * const cs_etm_global_header_fmts[] = { ^~~~~~~~~~~~~~~~~~~~~~~~~
What toolchain and/or version are you using?
$ uname -a # kernel & perf commit IDs match except from that one commit Linux juno 4.11.0-rc1-gc508373 #1 SMP PREEMPT Mon Mar 13 14:31:40 CDT
2017 aarch64 GNU/Linux
$ for i in /sys/bus/coresight/devices/*/enable_sink; do echo 1 | sudo tee
$i; done
1 1 1 1
As mentioned previously - you do not need to enable any sinks when using perf.
OK.
$ sudo taskset -c 2 ./perf record -e cs_etm/@20070000.etr/u --per-thread
taskset -c 2 uname
failed to mmap with 12 (Cannot allocate memory)
That said I get this too if I do enable sinks. However as you say after the initial attempt the problem disappears.
Right, at least we have one problem reproduced on both sides now.
Same if I use sudo .... rather than root....
===================================================== mleach@linaro-developer:~/auto-fdo/example$ sudo taskset -c 2 ../../perf-tools/perf record -e cs_etm/@20070000.etr/u --per-thread taskset -c 2 uname -a Linux linaro-developer 4.11.0-rc1-gdd18d85-dirty #17 SMP PREEMPT Tue Mar 14 11:18:30 GMT 2017 aarch64 GNU/Linux
...technically that kernel is one revision behind, and I can't tell what difference made the -dirty, assuming it's ok...
Check you are using the correct .dtb for your board revison. (juno.dtb, juno-r1.dtb, juno-r2.dtb). Not sure how this would cause a hang, but it does explain the reduced amount of data you are capturing compared to my test runs.
I checked my setup, the -r2 dtb is being used, and, like you said in your follow-up email, this is likely because I'm using the r2's A72 cluster: I was following the autoFDO example in the documentation. Did you try that cluster too?
Otherwise I have attached my .config in case there are key differences there.
Same result with your config:
# taskset -c 2 ./perf record -e cs_etm/@20070000.etr/u --per-thread taskset -c 2 uname [ 79.851022] coresight-replicator-qcom 20120000.replicator: REPLICATOR enabled [ 79.858098] coresight-funnel 20150000.funnel: FUNNEL inport 0 enabled [ 79.864488] coresight-tmc 20010000.etf: TMC-ETF enabled [ 79.869666] coresight-funnel 20040000.funnel: FUNNEL inport 0 enabled [ 79.876060] coresight-funnel 220c0000.funnel: FUNNEL inport 1 enabled Linux [ 79.901860] coresight-funnel 220c0000.funnel: FUNNEL inport 1 disabled [ 79.908328] coresight-funnel 20040000.funnel: FUNNEL inport 0 disabled [ 79.914810] coresight-tmc 20010000.etf: TMC disabled [ 79.919727] coresight-funnel 20150000.funnel: FUNNEL inport 0 disabled [ 79.926189] coresight-replicator-qcom 20120000.replicator: REPLICATOR disabled [ 79.933355] coresight-tmc 20070000.etr: TMC-ETR disabled [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote
It hung before completing that last sentence.
Perhaps the bug is exasperated by toolchain and/or host and target rootfs distribution differences? My juno target runs debian, and I recently upgraded to stretch in order to get a version of gcc that would support autoFDO.
Kim