On 23 September 2016 at 11:30, liubowen (A) <liubowen2(a)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 like
> that. The cmd is “perf record –C 0 –e cs_etm/(a)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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Good day,
There is a lot of documentation around on how to use the CoreSight
framework and drivers. In the kernel tree the documentation directory
[1] is a good place to start. Regarding the integration with perf and
how that works with the rest of the solution you are encouraged to
visit the openCSD github site [2]. There the "HOWTO.md" on the master
branch has all the details needed to get the solution going.
That being said the release of kernel v4.8 is imminent (Sunday
September 25th to be exact) and with it comes a lot of new
functionality. I will be rebasing all the out of tree code to v4.8
along with updating the documentation next week - by Friday September
20th everything should be in good standing.
In the mean time you can read the current HOWTO.md to get familiar
with the solution, that is probably a good time investment.
Thanks,
Mathieu
[1]. http://lxr.free-electrons.com/source/Documentation/trace/coresight.txt
[2]. https://github.com/Linaro/OpenCSD
On 21 September 2016 at 04:27, Kaiyou Wang <Kaiyou.Wang(a)arm.com> wrote:
> Hi Mathieu,
>
>
>
> This is Kaiyou from ARM, I find the Coresight drive in Linaro kernel code
> “kernel-release/drivers/hwtracing/coresight”.
>
> Could you give me any documents how to use the Coresight driver in Linaro
> Kernel?
>
>
>
> Thanks and Best Regards,
>
> Kaiyou
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
Hi Mathieu:
I am bob. And thanks for your time as always!
In the past for a while, I worked based on our kernel and applied the patches about coresight from “perf-opencsd-4.7”. However, it is not successful.
So, I work based on your kernel “perf-opencsd-4.7”, and add some drivers about the board made from Hisilicon. In theory, it should go well. But I get the
same error. When I use perf to record data, the record will stop for a long time. And I check the source code and the program will stay in “perf_evlist__poll”
and do not return just as follow.
[cid:image008.jpg@01D20A2E.C3BE2EC0]
So I use “Ctrl + C” to stop record, and I get the bug as follow.
[cid:image001.png@01D20A24.E814E6B0]
[cid:image002.png@01D20A26.DF7334B0]
On the other hand, I do a test as follow.
[cid:image009.jpg@01D20A2E.C3BE2EC0]
In the source code, when we use the ETR mode, it will allocate 1M space as follow.
[cid:image010.jpg@01D20A2E.C3BE2EC0]
So, the coresight turns out to work well. Here, I have another question, when I change “SZ_1M” to a value bigger than 1M such as “SZ_2M”, and I try to enable
the etr device, I get the error “cannot allocate memory”.
And I am sorry to trouble you, can you give me some suggestion? It really take a lot of my time to work on the project, I hope I can success finally.
Thanks very much for your time and all your help!!
Best regards!
Bob
On 23 August 2016 at 10:24, liubowen (A) <liubowen2(a)huawei.com> wrote:
> Hi Mathieu,
>
> I am Bob.
>
>
>
> I still get stuck. I feel not good. However, I should move on.
>
> The reason why I fail is as follows.
>
>
>
>
>
> On current station, I work on the board similar to D02 made from
> Hisilicon. And the Image comes from “4.7.0-rc2” into which we have added a
> lot drivers related with the board.
>
>
>
> From the log from git, the latest change about coresight for “4.7.0-rc2”
> is “2016-05-21”. But “perf-opencsd-4.7” has changed a lot after the point
> “2016-05-21”.
>
>
>
>
>
> Maybe ,the problem is here. I make a “perf” executable from
> “perf-opencsd-4.7”, but the coresight drivers used to generate trace data
> aren’t complete. The drivers come from “4.7.0-rc2” not “perf-opencsd-4.7”.
>
>
>
> So, I intend to make a Image from the branch “perf-opencsd-4.7”,
> but there is a lot of work in adding relational drivers with the board. I
> give up this way for the moment.
>
>
>
> So, I want to add complete coresight driver from “perf-opencsd-4.7” into
> “4.7.0-rc2” which I am working on. Can you help me? Can you offer me the
> whole patches about coresight and others necessary?
>
> I have tried to compare the file from the two branches, and make the
> relational files same to the files in “perf-opencsd-4.7” by hand, but it is
> not clever.
>
>
>
> I am sorry to trouble you. I hope my question is clear for you. Howevew,
> thanks very much for your time!!
>
>
>
> Best regards!
>
>
>
> Bob
>
You have found the problem - congratulation. I am working very hard on
upstreaming all the out-of-tree code available on github
(perf-opencsd-4.8-rc1) but it will probably take a few more kernel cycle
before everything finds its way mainline.
I am not sure how else I can help you, or if I can help you at all. All
the code is publicly available and updated with each new kernel cycle.
Best regards,
Mathieu
Hi All,
The first version of draft [1] just finished on google docs, it will
be (I hope) published as the September Core Dump article as we
expected. I tried my best to make the words and sentences in this
documentation clear and correct though, there must be some mistakes I
believe :)
Please have a look and any comments and advices would be greatly appreciated.
I've added a few person in the can-edit list, but I don't know exactly
all email addresses which are in this list, so you may find yourself
don't have the edit authority, if that's the case please let me know,
or you can simply comment on email.
Many thanks,
Chunyan
[1] https://docs.google.com/document/d/16YICrRW4Tm51uU8bMgtJ2hR_VQyEqiTBd4wlA55…
OpenCSD v0.4 provides a more scaleable and generic API for decoder
creation. This patch fixes the cs-etm-decoder in perf report to use
the new API.
Removes the deprecated protocol specific C API function calls used to
create decoders, replacing them with the general create by protocol name
API introduced in OpenCSD v0.4
Fix typename move from C API to more global ocsd_ API types.
Signed-off-by: Mike Leach <mike.leach(a)linaro.org>
---
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 31 +++++++++++++++++++------
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index ef36f02..a76109c 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -253,6 +253,7 @@ static int cs_etm_decoder__create_etmv4i_packet_printer(struct cs_etm_decoder_pa
{
ocsd_etmv4_cfg trace_config;
int ret = 0;
+ unsigned char CSID; /* CSID extracted from the config data */
if (d_params->packet_printer == NULL)
return -1;
@@ -264,11 +265,20 @@ static int cs_etm_decoder__create_etmv4i_packet_printer(struct cs_etm_decoder_pa
decoder->packet_printer = d_params->packet_printer;
- ret = ocsd_dt_create_etmv4i_pkt_proc(decoder->dcd_tree,
- &trace_config,
- cs_etm_decoder__etmv4i_packet_printer,
- decoder);
+ ret = ocsd_dt_create_decoder(decoder->dcd_tree,
+ OCSD_BUILTIN_DCD_ETMV4I,
+ OCSD_CREATE_FLG_PACKET_PROC,
+ (void *)&trace_config,
+ &CSID);
+ if (ret != 0)
+ return -1;
+
+ ret = ocsd_dt_attach_packet_callback(decoder->dcd_tree,
+ CSID,
+ OCSD_C_API_CB_PKT_SINK,
+ cs_etm_decoder__etmv4i_packet_printer,
+ decoder);
return ret;
}
@@ -277,6 +287,8 @@ static int cs_etm_decoder__create_etmv4i_packet_decoder(struct cs_etm_decoder_pa
{
ocsd_etmv4_cfg trace_config;
int ret = 0;
+ unsigned char CSID; /* CSID extracted from the config data */
+
decoder->packet_printer = d_params->packet_printer;
ret = cs_etm_decoder__gen_etmv4_config(t_params,&trace_config);
@@ -284,9 +296,13 @@ static int cs_etm_decoder__create_etmv4i_packet_decoder(struct cs_etm_decoder_pa
if (ret != 0)
return -1;
- ret = ocsd_dt_create_etmv4i_decoder(decoder->dcd_tree,&trace_config);
+ ret = ocsd_dt_create_decoder(decoder->dcd_tree,
+ OCSD_BUILTIN_DCD_ETMV4I,
+ OCSD_CREATE_FLG_FULL_DECODER,
+ (void *)&trace_config,
+ &CSID);
- if (ret != OCSD_OK)
+ if (ret != 0)
return -1;
ret = ocsd_dt_set_gen_elem_outfn(decoder->dcd_tree,
@@ -294,6 +310,7 @@ static int cs_etm_decoder__create_etmv4i_packet_decoder(struct cs_etm_decoder_pa
return ret;
}
+
int cs_etm_decoder__add_mem_access_cb(struct cs_etm_decoder *decoder, uint64_t address, uint64_t len, cs_etm_mem_cb_type cb_func)
{
int err;
@@ -312,7 +329,7 @@ int cs_etm_decoder__add_mem_access_cb(struct cs_etm_decoder *decoder, uint64_t a
int cs_etm_decoder__add_bin_file(struct cs_etm_decoder *decoder, uint64_t offset, uint64_t address, uint64_t len, const char *fname)
{
int err = 0;
- file_mem_region_t region;
+ ocsd_file_mem_region_t region;
(void) len;
if (NULL == decoder)
--
2.7.4
On 11 August 2016 at 08:56, liubowen (A) <liubowen2(a)huawei.com> wrote:
> Hi Mathieu:
>
>
>
> I am bob. Thanks for your time.
>
>
>
> Now, I want to enable ETR to store trace messages instead of ETB, of which
> the size is only 16KB. Maybe the size is not large enough, the perf.data is
> not complete, and something goes wrong. And Chunyan Zhang also
>
> suggests me try ETR. Here, many thanks to Chunyan Zhang at the same time.
> ^_^
>
>
>
> What I want is like as follows, CoreSight blocks are listed in the device
> tree for a specifiv system and discovered at boot time.
>
>
>
By the way, what board is this?
> So, I follow the Documentation/devicetree/bindings/arm/coresight.txt
> which is in the kernel. However this doc tells us how to configure the ETB
> without ETR. In fact, ETR is a little more complex.
>
> I tried to configure ETR in the DTS according to the master and slave
> relations among CoreSight blocks, buf failed finally.
>
>
>
> Here , can you show me a DTS demo including the configuration of ETR when
> you are really convenient. I will be very sorry if I do trouble you.
>
>
>
> Thanks for your time!!
>
>
>
> Best Regards,
>
>
>
> Bob
>
