Hi,
On 21 December 2016 at 02:40, Mathieu Poirier mathieu.poirier@linaro.org wrote:
On 19 December 2016 at 07:45, Yehuda Yitschak yehuday@marvell.com wrote:
Hi Mathieu
After some more debug I was able to resolve the trace issue I had on Linux-4.9-rc1
If you remember I only got trace for CPU2 out of 4 CPUs which was really strange
Turns out the issue comes from some quirk in our busses
Our internal fabric is not able to write 64bit data to registers, only to memory
So the address comparators in the ETM got corrupted values and there
wasn’t
any match on address for most CPUs.
For some cryptic reason only CPU2 got somewhat reasonable comparator
value
(still not the intended, but a working one) and so it could generate
trace
Now I am able to generate proper trace consistently.
Very good.
I was wondering how can I add latency or timing information to the trace
I noticed the cs_etm event can accept an option of “cycacc” and
“timestamp“
How can I view this information later ?
Should I use perf script –f ?
That information, when configured on the cmd line, will end up in the perf.data file. From there it will be decoded and rendered by the openCSD library.
Mike, can you comment on the format of the information that will be found in the packet? Perhaps you have an example somewhere of traces generated by the "cycacc" and "timestamp" option?
In principle the cycle counts are generated according to the cycle_count
threshold - which means you will not ordinarily get a cycle count per instruction on ETMv4. This is to avoid flooding the trace data with lots of cycle count packets. The threshold is programmable but I am not sure what value is used by the etmv4 driver.
Timestamps are generated periodically at useful events such as trace synchronisation points, exception entry and return etc.
I tested the cycacc and timestamp options on Juno this morning and found that cycle accurate tracing did not seem to be enabled at all and timestamps appeared to all be 0x0 (from the packet printing in perf report --dump). These are probably two separate issues that require further investigation. My initial check on the perf cs-etm-decoder.c file showed that an incorrect value of TRCCONFIGR appeared to be passed to the decoder - matching the correct configuration for ETMv3 with CC and TS enabled rather than ETMv4.
Finally, again reading the code in cs-etm-decoder.c, even if we get correct timestamp and cycle count packets, the processing appears to be ignoring them - focussing on instruction ranges and exceptions to enable the trace disassembly. So I cannot see how these packets are used or transmitted to the output of perf script / report.
I am not familiar with this area of the code so I could be mis-reading it - the relevant code could be elsewhere?
Regards
Mike
You will definitely need to create your own scripts as nothing we have done so far uses those configuration parameters.
Thanks, Mathieu
Thanks a lot
Yehuda Yitschak
Marvell Semiconductor Ltd.