[igt-dev] [PATCH i-g-t 3/3] lib: Enable extra kernel logs for audio debug

[Arkadiusz Hiler]

On Tue, Apr 16, 2019 at 05:06:39PM +0200, Daniel Vetter wrote:
> On Tue, Apr 02, 2019 at 05:45:35PM -0700, Ashutosh Dixit wrote:
> > For debug of audio issues in power management and driver reload tests,
> > additional kernel logs may be useful, both in dmesg as well as
> > ftrace. Add the infrastructure to generate these logs and enable these
> > logs for selected tests.
> > 
> > At present igt_runner and other CI infrastructure does not capture the
> > ftrace buffer. Therefore, to avoid changes to igt_runner and the CI
> > infrastructure the ftrace buffer is dumped to stdout at the end of
> > each test.
> > 
> > v5: use ARRAY_SIZE(), s/audio_klog/audio_dmesg_and_ftrace/
> > v4: remove system() calls, dump audio kernel logs from igt_fixture
> > v2, v3: versions to fix CI
> > 
> > Cc: Jani Nikula <jani.nikula at linux.intel.com>
> > Signed-off-by: Ashutosh Dixit <ashutosh.dixit at intel.com>

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109189

Ashutosh, if you have a bug (freedesktop, kernel.org) associated to the
work you are doing it is helpful to link it for the context.

> I think it would be good to integrate this a bit tigther into igt
> infrastructure:
> - use an exit handler to do the cleanup, that will also handle aborts and
>   stuff like that
> - only dump the ftrace buffer if we fail a subtest, and dump it
>   immediately. Similar to how we dump the entire igt debug crash recorder
>   already. One issue could be tests where the test passes, but we get some
>   kernel backtrace and we'd still like to see an ftrace. Maybe we need to
>   pull the tainting checks into subtest exit code (shared with the
>   runner).
> - enable useful ftrace debug stuff by default on all tests. If it's
>   useful, it's probably useful in unexpected places too. Of course this
>   means we need to check to make sure those events are present first
>   before we try to enable them.
> 
> In general I think this is really good, there's lots of bugs and issue
> that would benefit from capturing some ftrace of what's been going on
> right before the test blew up.
> -Daniel

+1 on this idea. Those audio issues desperately need the extra logging,
but baking it into the framework would not only streamline the
implementation here (dump on failed assert, etc.) but benefit all the
tests.

If something is not clear feel free to ask here or on the IRC (danvet/ivyl) :-)

-- 
Cheers,
Arek