Great to hear, Sebastian! :) The "failed to mmap" was the same error I got, as well.
Is this a good place to talk about perf inject machinery, or should I start a new thread for that?
If this is the right place, it looks like the traces from my hikey might not be getting read properly by `perf inject` when I'm trying to generate LBR traces. A bit of debugging has shown that many of the traces can be decoded, but we eventually hit one of type ETM4_PKT_I_COND_I_F2, which TrcPktDecodeEtmV4I::decodePacket currently doesn't support.
I'm reading the docs, and it looks like that kind of tracing needs to be explicitly enabled. Doing `cat /sys/bus/coresight/devices/*.etm/mode`, the bits to enable that all appear clear on my setup. So, I'm unsure how it's sneaking into the traces. I found a convenient way to dump the traces (cs_etm__dump_event), and it looks like there may be some invalid traces in perf.data, as well?
In any case, I've attached three things in one tarball: - perf.data from running a bubble sort program on Hikey for a few ms; recorded using `taskset 1 ./perf record -e cs_etm/@f6404000.etr/u --per-thread ./gbiv-tool` - etm-dump.txt, which is stdout from running `perf --debug verbose=9 inject -i ./perf.data -o lbr_trace --itrace=i100usl64 --strip` (with a call to cs_etm__dump_event baked in) - lbr_trace, the (nearly empty?) output of the trace.
When trying to convert lbr_trace to an LLVM profile, I get errors about 0% of the samples being mappable onto the executable.
I'm running perf on my x86 machine from the opencsd 4.11 branch; opencsd was freshly pulled+compiled earlier today.
I'll continue trying to figure out the root cause tomorrow.
On Wed, May 31, 2017 at 10:56 AM, Mathieu Poirier < mathieu.poirier@linaro.org> wrote:
On 31 May 2017 at 11:09, Sebastian Pop sebpop@gmail.com wrote:
On Tue, May 23, 2017 at 1:44 AM, George Burgess gbiv@google.com wrote:
Right; sorry, I'm tired. :) I was a bit sneaky with the ARM patch,
since I'm
using Android+fastboot with this kernel, as I think you are.
In particular, I modified Li Pengcheng's sysconf patch to also flip the
bits
that the ARM patch does. It seems that this works just as well (and is convenient, since that patch already ioremaps the region that the arm-tf patch writes to). New hi6220-sysconfig.c patch is attached.
I tried applying this patch to 4.9, as well. I was able to get the
device to
boot and recognize its ETMs, but perf dies seemingly because `sink_ops(sink)->alloc_buffer == NULL` (coresight-etm-perf.c; line
241ish).
Trying to apply a patch to make that work gave me a build error, which I didn't look too much into; I'm perfectly fine with my kernel not being
near
AOSP's HEAD for the moment. :)
If you'd like, I'm happy to gather the hacks I made to make 4.11 play
nicely
with AOSP and put them in patch form tomorrow. It was mainly just me
adding
bits and pieces to Makefiles and crossing my fingers.
Thanks George for the patch. I got the AOSP linux kernel 4.9 working with CoreSight with the attached patches. I can see the ETM components:
hikey:/ # ls /sys/bus/coresight/devices/ amba:replicator@0/ f6501000.funnel/ f659f000.etm/
f65df000.etm/
f6401000.funnel/ f659c000.etm/ f65dc000.etm/ f6402000.etf/ f659d000.etm/ f65dd000.etm/ f6404000.etr/ f659e000.etm/ f65de000.etm/
However perf does not collect traces yet: it fails with some malloc
problem
(maybe the same problem as what you reported above)
# perf record -e cs_etm/@f6404000.etr/u --per-thread failed to mmap with 12 (Cannot allocate memory)
The perf interface for ETR isn't part of mainline yet. There is a driver available on github (also for kernel 4.9) that should apply cleanly on top of AOSP. ETF support is available in mainline and should work out of the box.
I will try to run perf under gdb and see where and why this fails.
Sebastian