<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 5, 2021 at 10:45 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 05/03/2021 16:11, <a href="mailto:Jan.Sommer@dlr.de" target="_blank">Jan.Sommer@dlr.de</a> wrote:<br>
<br>
> Some of the resulting CTF events have a very large timestamp. This only occurs for events of which are created by CPUs other than CPU0, but not all of them.<br>
> I ran rtems-record-lttng in gdb and could track it to record-client.c:176 (<a href="https://git.rtems.org/rtems-tools/tree/trace/record/record-client.c#n176" rel="noreferrer" target="_blank">https://git.rtems.org/rtems-tools/tree/trace/record/record-client.c#n176</a>).<br>
> There the (delta * ctx->to_bt_scaler ) causes an overflow and sets per_cpu-><a href="http://uptime.bt" rel="noreferrer" target="_blank">uptime.bt</a> to a very large negative number which then later becomes a very large (positive) timestamp.<br>
><br>
> I have some trouble figuring out what is going wrong here. The timestamps which are read from the rtems record events looks quite reasonable to me.<br>
> The to_bt_scaler is quite a large value and I don't fully get what it scales. Does someone have some hints?<br>
It could be related to ring buffer overflows. Do you get <br>
RTEMS_RECORD_PER_CPU_OVERFLOW items? There could be also some bugs in <br>
record-client.c. More unit tests for it would be helpful.<br></blockquote><div><br></div><div>Asking stupidly, are there tests now? We didn't catch that libtrace was missing in the new coverage reports:<br><br><a href="https://ftp.rtems.org/pub/rtems/people/joel/coverage/coverage-2021-02-28/">https://ftp.rtems.org/pub/rtems/people/joel/coverage/coverage-2021-02-28/</a></div><div><br></div><div>I can add it to the queue that libtrace is added. If more subsystems </div><div>are missing that we want to track coverage on, please point them out.</div><div><br></div><div>--joel </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
embedded brains GmbH<br>
Herr Sebastian HUBER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 16<br>
fax:   +49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
<br>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a></blockquote></div></div>