On 23 September 2016 at 11:30, liubowen (A) liubowen2@huawei.com wrote:
Hi Mathieu:
I am bob. And I go to bother you again. ^_^ Now, the trace data can be written into perf.data, just likethat. The cmd is “perf record –C 0 –e cs_etm/@sink=44001000.etr/ uname”.
Any particular reason why you want to trace on CPU 0 only? Using the "--per-thread" option will tell Perf to follow execution of your program on any CPU the scheduler choose to put it on.
However, when I want to report the perf.data, I get the error message just like that.
Have you ever met this problem?
No I haven't. This is a user space problem and has nothing to do with the coresight drivers.
I am also working hard to solve this problem by myself. I have spent some time on studing the coresight drivers code by adding print . When we use perf to record trace data, it goes like that, from my opinion,
It is only what I think based on the print message added into the kernel by myself. I am not sure it is true.
This looks about right.
And the perf.data contains two AUXTRACE instance in my case.
Right, those are areas of the file containing CoreSight trace data.
If true, I have some questions here. Because we want to get the continuous flow of instructions using coresight, between (1) and (2), the corsight is in state of stopped or disabled, finally we
will get discontinuous flow of instructions. Do you think so?
The cool thing about Perf is that when a process is scheduled for execution it tells the PMU to start tracing. The same thing happens when the process is taken off a CPU either because it has terminated, it is waiting on some IO to finish or it is preempted. In (1) the process has been scheduled on a CPU and was running until it was scheduled out (for some reason). In (2) the process is ready to run again and as such CS is enabled again.
You don't want to know what is happening between (1) and (2) as it is not relevant for that trace session.
On the other hand, in my test case, only the trace data made from (1) and (2) are written into perf.data, but the trace data made from (3) does not. I don’t know why. And I have another question annoyed me,
when (1) is done, which one condition is to trigger (2)? I think it is something about perf, and I have studied the perf code, and still confused.
There is no need to study the perf code - it is very complex. (2) gets started when the process is scheduled on a CPU again.
And everytime the record is done, I will also get the bug info like that. I am working on version 4.7 from your kernel, I have tried to use version 4.8 from your kernel, but the same bug info. Have you ever met?
That is bizarre, especially since you are using the the ETR driver. From what I can tell memory is being freed while a spinlock is held. Did you happen to change the code at all?
Kernel version 4.8 will be released on Sunday - I am currently writing the documentation (HOWTO.md) that goes with it. I suggest to move to that version since a lot of code has gone in. Make sure to read the documentation, some of user space has changed. That should all be ready by next Friday (September 30th).
I am sorry to trouble you. And Thanks very much for your time. I am a beginner, and beg your pardon. And I am interested in your project, I hope I can make it come true on my platform.
And, as you say, I do not get a good understanding of the coresight. So I have spent some time on reading the CoreSight_Architecture_Specification and CoreSight Trace Memory Controller recently. I get a lot. However
I still need your suggestions. Thanks very very much!
There is a lot of concept to master before understanding CoreSight. It might not be obvious now but all that debugging you're doing will definitely help in the future.
Best regards.
Bob.
