<div dir="ltr"><div dir="ltr"><div dir="ltr">>> I increased the buffer size of each cpu core in /sys/kernel/debug/buffer_size_kb, but the problem still exists!<br>
<br><div>
> I’m not sure how you hit on that setting, but I don’t think it has 
anything to do with LITMUS^RT. The LITMUS^RT trace buffers are 
configured statically via .config.</div><div><br></div><div>To clarify: "/sys/kernel/debug/tracing/buffer_size_kb" is an ftrace configuration parameter (<a href="https://www.kernel.org/doc/Documentation/trace/ftrace.txt">https://www.kernel.org/doc/Documentation/trace/ftrace.txt</a>).  Linux's ftrace is distinct from Litmus's "feather trace."  The size of feather trace buffers is controlled by the .config parameter CONFIG_SCHED_TASK_TRACE_SHIFT (see litmus/Kconfig).</div><div><br></div><div>-Glenn<br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 21, 2019 at 8:45 AM Björn Brandenburg <<a href="mailto:bbb@mpi-sws.org">bbb@mpi-sws.org</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"><br>
<br>
> On 20. May 2019, at 18:35, sobhan niknam <<a href="mailto:sobhan.niknam@yahoo.com" target="_blank">sobhan.niknam@yahoo.com</a>> wrote:<br>
> <br>
> <br>
> <br>
>> On 20 May 2019, at 17:40, Björn Brandenburg <<a href="mailto:bbb@mpi-sws.org" target="_blank">bbb@mpi-sws.org</a>> wrote:<br>
>> <br>
>> On 20. May 2019, at 16:40, sobhan niknam <<a href="mailto:sobhan.niknam@yahoo.com" target="_blank">sobhan.niknam@yahoo.com</a>> wrote:<br>
>>> <br>
>>> There is no log file in /dev/litmus to look at.<br>
>> <br>
>> I’m not talking about a LITMUS^RT-specific device file. Check the standard kernel log. <br>
> <br>
> The buffers overflowed: <br>
> <br>
> May 21 01:12:37 odroid kernel: [341828.508325] [c1] Failed trace writes: 25486<br>
> May 21 01:12:37 odroid kernel: [341828.508344] [c3] Failed trace writes: 46617<br>
> May 21 01:12:37 odroid kernel: [341828.508364] [c0] Failed trace writes: 19335<br>
> May 21 01:12:37 odroid kernel: [341828.508381] [c2] Failed trace writes: 0<br>
> May 21 01:12:37 odroid kernel: [341828.508619] [c2] Failed trace writes: 6915121<br>
> May 21 01:12:37 odroid kernel: [341828.508627] [c0] Failed trace writes: 6713421<br>
> May 21 01:12:37 odroid kernel: [341828.508696] [c3] Failed trace writes: 23201<br>
> May 21 01:12:37 odroid kernel: [341828.511328] [c3] Failed trace writes: 7169319<br>
<br>
Makes sense. If you have gaps in the record, then of course the resulting traces will be incomplete and/or strange. <br>
<br>
> <br>
>>> However, what should I do if supposing the trace buffers overflowed?<br>
>> <br>
>> If you have enough memory, increase the trace buffer size. Otherwise, make sure they get drained quickly enough. <br>
> <br>
> <br>
> I increased the buffer size of each cpu core in /sys/kernel/debug/buffer_size_kb, but the problem still exists!<br>
<br>
I’m not sure how you hit on that setting, but I don’t think it has anything to do with LITMUS^RT. The LITMUS^RT trace buffers are configured statically via .config. <br>
<br>
- Björn<br>
<br>
<br>
_______________________________________________<br>
litmus-dev mailing list<br>
<a href="mailto:litmus-dev@lists.litmus-rt.org" target="_blank">litmus-dev@lists.litmus-rt.org</a><br>
<a href="https://lists.litmus-rt.org/listinfo/litmus-dev" rel="noreferrer" target="_blank">https://lists.litmus-rt.org/listinfo/litmus-dev</a><br>
</blockquote></div>