[igt-dev] [PATCH i-g-t 1/2] lib: Add hooks for enabling ftrace

Chris Wilson chris at chris-wilson.co.uk
Tue Mar 19 09:06:53 UTC 2019


Quoting Ashutosh Dixit (2019-03-19 04:26:51)
> On Sat, 16 Mar 2019 02:25:04 -0700, Chris Wilson wrote:
> >
> > If the kernel has tracing support builtin, we can enable around
> > troublesome tests to obtain greater detail from the kernel that may
> > prove invaluable in debugging the problem.
> >
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> 
> I have a few general comments on the patch. I have submitted a patch [1]
> which has some overlap with the functionality enabled here so I am thinking
> if it is possible to combine the best parts of both the patches.

Hence why I dug up this patch from a couple of years ago and sent it in
your direction...

> I am aware
> that coming up with a general hard-coded solution for these sort of traces
> is difficult.
> 
> a. Is the function graph tracer the most useful tracer to use as is done in
>    this patch? Or a nop tracer, or it doesn't matter?

Depends on situation. I want to work more with the latency-tracer and
irqsoff-tracer.

> b. Do we need to increase the size of the ftrace ring to reduce the
>    likelihood of the ftrace ring overflow?

Unlikely, if you overflow the ftrace you are dumping too much irrelevant
noise an you will never find the bug anyway. If the test isn't designed
to catch and stop on the bug, you will be hard pressed to find it.

> c. This patch dumps out the ftrace buffer when there is a kernel
>    oops. However, afaik, the audio issues we are seeing result in test
>    failures but there are no oops.

There is a function to grab the ftrace log, deciding when to call that I
left as an exercise for the reader. I generally just read it via
netconsole anyway.

> d. Even when there is an oops, ftrace output from this patch will contain
>    the output from all previous sub-tests, not just the sub-test which
>    caused the oops. I had tried to take care of c. and d. in my patch.

Sure, as is normally the case. A big, big reason why I keep pushing for
kmsg capture to be integral to igt.
-Chris


More information about the igt-dev mailing list