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