On 17 April 2017 at 10:45, Bamvor Zhang Jian bamvor.zhangjian@linaro.org wrote:
Hi,
On 17 April 2017 at 21:21, Mathieu Poirier mathieu.poirier@linaro.org wrote:
[snip]
I have been travelling for the last two weeks and don't remember if I have answered this already.
The wrapping around is normal and can't be avoided. Problems happens when we get a wrap around and Perf decides to concatenate buffers in a single notification to user space. When that happens there is no way for the decoding library to know the boundaries of individual packets, resulting in a lost of synchronisation and proper decoding of traces.
This is very difficult to duplicate, hence taking a long time to deal with. I am still not sure about the conditions needed for Perf to concatenate buffers together.
Thanks for your expaination. So, will it be exist in the any senario?
Yes, this can happen in any scenario.
If so, I think we need this patch too. We encouter the wrong package recently and we have already use filter. How could we know if it is the same issue?
Sorry, I don't understand what you mean here by "wrong package" and the correlation is has on filters. Please explain further if you still need input on this.
'Wrong packages' seem a little bit misleading.
"packet" is the word you are looking for.
I would say there are some unexpected packages. Maybe I could send you the full log of packages tomorrow.
I won't be able to look at it.
In summary, we found the following issues respectively:
- We found that if we start etm in the start/stop range, sometimes the
first address package(a jump or an instruction after isb) may be lost. If we do a 100 times loop after the coresight timeout of etm enable. It will not lost the package. I suspect there are some configuration issues in our etm. But I do not find a clue right now. Is there some suggestion from your side?
I strongly suggest you purchase a dragonboard. That way you can reproduce the problems you are seeing on your platform on the dragonboard. That way it is much easier for us to work on issues you may encounter. This will be money well invested (they are very cheap).
Beleive me, I wish we could use the HiKey but CS support on that platform isn't very encouraging at this time (not for the lack of trying).
- We found that there are some full zero(64bit) packages. Is it usual?
It isn't no. Once again if you can reproduce this on a dragonboard I'd be happy to look at it. Otherwise it is impossible for me to help.
Therea are probably some other questions. But it is too late for me(midnight in beijing time). I could not recall the details. If I found other issues, I will send to you later.
Very well.
Mathieu
Thanks.
Bamvor
I saw the description of overflow. Could it monitor by CTI?
CTIs would indeed prevent this from happening.
Regards
Bamvor
Regards
Bamvor
> > Regards > > Bamvor >> After that I may be >> able to look at it if nothing else gets in the way.
Hi, Mathieus
On 18 April 2017 at 03:33, Mathieu Poirier mathieu.poirier@linaro.org wrote:
On 17 April 2017 at 10:45, Bamvor Zhang Jian bamvor.zhangjian@linaro.org wrote:
Hi,
On 17 April 2017 at 21:21, Mathieu Poirier mathieu.poirier@linaro.org wrote:
[snip]
I have been travelling for the last two weeks and don't remember if I have answered this already.
The wrapping around is normal and can't be avoided. Problems happens when we get a wrap around and Perf decides to concatenate buffers in a single notification to user space. When that happens there is no way for the decoding library to know the boundaries of individual packets, resulting in a lost of synchronisation and proper decoding of traces.
This is very difficult to duplicate, hence taking a long time to deal with. I am still not sure about the conditions needed for Perf to concatenate buffers together.
Thanks for your expaination. So, will it be exist in the any senario?
Yes, this can happen in any scenario.
If so, I think we need this patch too. We encouter the wrong package recently and we have already use filter. How could we know if it is the same issue?
Sorry, I don't understand what you mean here by "wrong package" and the correlation is has on filters. Please explain further if you still need input on this.
'Wrong packages' seem a little bit misleading.
"packet" is the word you are looking for.
I would say there are some unexpected packages. Maybe I could send you the full log of packages tomorrow.
I won't be able to look at it.
Sorry, I do not send it actually. It seems that there some configuration issue of coresight in our system.
In summary, we found the following issues respectively:
- We found that if we start etm in the start/stop range, sometimes the
first address package(a jump or an instruction after isb) may be lost. If we do a 100 times loop after the coresight timeout of etm enable. It will not lost the package. I suspect there are some configuration issues in our etm. But I do not find a clue right now. Is there some suggestion from your side?
I strongly suggest you purchase a dragonboard. That way you can reproduce the problems you are seeing on your platform on the dragonboard. That way it is much easier for us to work on issues you may encounter. This will be money well invested (they are very cheap).
I actually have a dragonboard. But I am in another city for a project, I just buy aother dragonboard. I am not sure if the dragonboard could help me on time.
Beleive me, I wish we could use the HiKey but CS support on that platform isn't very encouraging at this time (not for the lack of trying).
Understand. Although we could make coresight work in old android kernel.
- We found that there are some full zero(64bit) packages. Is it usual?
It isn't no. Once again if you can reproduce this on a dragonboard I'd be happy to look at it. Otherwise it is impossible for me to help.
I will try.
Therea are probably some other questions. But it is too late for me(midnight in beijing time). I could not recall the details. If I found other issues, I will send to you later.
Very well.
Thanks in advance.
Regards
Bamvor
Mathieu
Thanks.
Bamvor
I saw the description of overflow. Could it monitor by CTI?
CTIs would indeed prevent this from happening.
Regards
Bamvor
Regards
Bamvor >> >> Regards >> >> Bamvor >>> After that I may be >>> able to look at it if nothing else gets in the way.
On 18 April 2017 at 16:22, Bamvor Zhang Jian bamvor.zhangjian@linaro.org wrote:
Hi, Mathieus
On 18 April 2017 at 03:33, Mathieu Poirier mathieu.poirier@linaro.org wrote:
On 17 April 2017 at 10:45, Bamvor Zhang Jian bamvor.zhangjian@linaro.org wrote:
Hi,
On 17 April 2017 at 21:21, Mathieu Poirier mathieu.poirier@linaro.org wrote:
[snip]
I have been travelling for the last two weeks and don't remember if I have answered this already.
The wrapping around is normal and can't be avoided. Problems happens when we get a wrap around and Perf decides to concatenate buffers in a single notification to user space. When that happens there is no way for the decoding library to know the boundaries of individual packets, resulting in a lost of synchronisation and proper decoding of traces.
This is very difficult to duplicate, hence taking a long time to deal with. I am still not sure about the conditions needed for Perf to concatenate buffers together.
Thanks for your expaination. So, will it be exist in the any senario?
Yes, this can happen in any scenario.
If so, I think we need this patch too. We encouter the wrong package recently and we have already use filter. How could we know if it is the same issue?
Sorry, I don't understand what you mean here by "wrong package" and the correlation is has on filters. Please explain further if you still need input on this.
'Wrong packages' seem a little bit misleading.
"packet" is the word you are looking for.
I would say there are some unexpected packages. Maybe I could send you the full log of packages tomorrow.
I won't be able to look at it.
Sorry, I do not send it actually. It seems that there some configuration issue of coresight in our system.
In summary, we found the following issues respectively:
- We found that if we start etm in the start/stop range, sometimes the
first address package(a jump or an instruction after isb) may be lost. If we do a 100 times loop after the coresight timeout of etm enable. It will not lost the package. I suspect there are some configuration issues in our etm. But I do not find a clue right now. Is there some suggestion from your side?
I strongly suggest you purchase a dragonboard. That way you can reproduce the problems you are seeing on your platform on the dragonboard. That way it is much easier for us to work on issues you may encounter. This will be money well invested (they are very cheap).
I actually have a dragonboard. But I am in another city for a project, I just buy aother dragonboard. I am not sure if the dragonboard could help me on time.
Beleive me, I wish we could use the HiKey but CS support on that platform isn't very encouraging at this time (not for the lack of trying).
Understand. Although we could make coresight work in old android kernel.
- We found that there are some full zero(64bit) packages. Is it usual?
It isn't no. Once again if you can reproduce this on a dragonboard I'd be happy to look at it. Otherwise it is impossible for me to help.
I will try.
Therea are probably some other questions. But it is too late for me(midnight in beijing time). I could not recall the details. If I found other issues, I will send to you later.
Very well.
Thanks in advance.
Regards
Bamvor
Mathieu
Thanks.
Bamvor
I saw the description of overflow. Could it monitor by CTI?
CTIs would indeed prevent this from happening.
Regards
Bamvor
> > Regards > > Bamvor >>> >>> Regards >>> >>> Bamvor >>>> After that I may be >>>> able to look at it if nothing else gets in the way.
-
Bamvor Zhang Jian -
Mathieu Poirier -
Mike Leach