[re-adding cc list, assuming didn't hit reply-all?]
On Tue, 14 Mar 2017 19:12:08 +0000 Mike Leach mike.leach@linaro.org wrote:
On 14 March 2017 at 16:10, Kim Phillips kim.phillips@arm.com wrote:
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?
I'm using a linaro build of gcc 4.9.
aarch64-linux-gnu-gcc (Linaro GCC 4.9-2015.05) 4.9.3 20150413 (prerelease)
Linaro appear to have removed that release from their repo:
http://releases.linaro.org/components/toolchain/binaries/
So I used this one - which AFAICT is the closest to your version - to cross-build both the kernel with your config, and perf:
aarch64-linux-gnu-gcc (Linaro GCC 4.9-2016.02) 4.9.4 20151028 (prerelease)
Building perf didn't require the patch I sent due to an old gcc bug that apparently finally got fixed recently:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
I then ran the resulting kernel (which still had the extra patch, so commit 0d15341 == c50837 + the patch), and perf:
root@juno:~# ./perf --version perf version 4.11.rc1.gc50837 root@juno:~# strings -a perf | grep "GCC: (" GCC: (Linaro GCC 4.9-2016.02) 4.9.4 20151028 (prerelease) root@juno:~# dmesg | grep gcc [ 0.000000] Linux version 4.11.0-rc1-g0d15341 (kim@dupont) (gcc version 4.9.4 20151028 (prerelease) (Linaro GCC 4.9-2016.02) ) #3 SMP PREEMPT Tue Mar 14 22:41:34 CDT 2017 root@juno:~# taskset -c 2 ./perf record -e cs_etm/@20070000.etr/u --per-thread taskset -c 2 uname [ 870.355660] coresight-replicator-qcom 20120000.replicator: REPLICATOR enabled [ 870.362736] coresight-funnel 20150000.funnel: FUNNEL inport 0 enabled [ 870.369127] coresight-tmc 20010000.etf: TMC-ETF enabled [ 870.374304] coresight-funnel 20040000.funnel: FUNNEL inport 0 enabled [ 870.380698] coresight-funnel 220c0000.funnel: FUNNEL inport 1 enabled [ 870.387858] coresight-funnel 220c0000.funnel: FUNNEL inport 1 disabled [ 870.394325] coresight-funnel 20040000.funnel: FUNNEL inport 0 disabled [ 870.400806] coresight-tmc 20010000.etf: TMC disabled [ 870.405722] coresight-funnel 20150000.funnel: FUNNEL inport 0 disabled [ 870.412184] coresight-replicator-qcom 20120000.replicator: REPLICATOR disabled [ 870.419350] coresight-tmc 20070000.etr: TMC-ETR disabled [ 870.425083] coresight-replicator-qcom 20120000.replicator: REPLICATOR enabled [ 870.432153] coresight-funnel 20150000.funnel: FUNNEL inport 0 enabled [ 870.438542] coresight-tmc 20010000.etf: TMC-ETF enabled [ 870.443718] coresight-funnel 20040000.funnel: FUNNEL inport 0 enabled [ 870.450112] coresight-funnel 220c0000.funnel: FUNNEL inport 1 enabled Linux [ 870.476156] coresight-funnel 220c0000.funnel: FUNNEL inport 1 disabled [ 870.482625] coresight-funnel 20040000.funnel: FUNNEL inport 0 disabled [ 870.489106] coresight-tmc 20010000.etf: TMC disabled [ 870.494023] coresight-funnel 20150000.funnel: FUNNEL inport 0 disabled [ 870.500485] coresight-replicator-qcom 20120000.replicator: REPLICATOR disabled [ 870.507651] coresight-tmc 20070000.etr: TMC-ETR disabled [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 0.015 MB perf.data ]
which appears to have worked the first time.
Then I tried a second time - literally up-arrow, enter - and got the same exact hard hang as I get with the modern compilers the first time:
root@juno:~# taskset -c 2 ./perf record -e cs_etm/@20070000.etr/u --per-thread taskset -c 2 uname [ 1965.355162] coresight-replicator-qcom 20120000.replicator: REPLICATOR enabled [ 1965.362238] coresight-funnel 20150000.funnel: FUNNEL inport 0 enabled [ 1965.368629] coresight-tmc 20010000.etf: TMC-ETF enabled [ 1965.373807] coresight-funnel 20040000.funnel: FUNNEL inport 0 enabled [ 1965.380201] coresight-funnel 220c0000.funnel: FUNNEL inport 1 enabled Linux [ 1965.405984] coresight-funnel 220c0000.funnel: FUNNEL inport 1 disabled [ 1965.412453] coresight-funnel 20040000.funnel: FUNNEL inport 0 disabled [ 1965.418934] coresight-tmc 20010000.etf: TMC disabled [ 1965.423850] coresight-funnel 20150000.funnel: FUNNEL inport 0 disabled [ 1965.430312] coresight-replicator-qcom 20120000.replicator: REPLICATOR disabled [ 1965.437478] coresight-tmc 20070000.etr: TMC-ETR disabled [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote
which is along the same instability lines as the other time that execution behaviour differed depending on whether it executed first or not...
$ 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.
...here.
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.
My juno is has a debian-jessie-developer root-fs from http://releases.linaro.org/debian/images/developer-arm64/16.04/ At present I cannot build autofdo - I still have some package issues, but for perf and the kernel I am x-compiling on my ubuntu VM anyway, so the installed compilers have no effect on the perf runs,.
OK, can you try a more modern toolchain please? The one you're using isn't available anymore, AutoFDO requires gcc 5 and higher, and you're not seeing the build failures others see, but most importantly, it should make it easier to reproduce the hard lockup: at least that's the case on the Juno r2.
Thanks,
Kim