[Intel-gfx] [igt-dev] [RFC PATCH i-g-t v2 1/8] tests/core_hotunplug: Duplicate debug messages in dmesg

[Arkadiusz Hiler]

On Fri, Jun 26, 2020 at 12:18:00PM +0200, Janusz Krzysztofik wrote:
> Hi Michał,
> 
> Thanks for review.
> 
> On Thu, 2020-06-25 at 17:27 +0200, Michał Winiarski wrote:
> > Quoting Janusz Krzysztofik (2020-06-22 18:44:08)
> > > The purpose of debug messages displayed by the test is to make
> > > identification of a subtest phase that fails more easy.  Since issues
> > > exhibited by the test are mostly reported to dmesg, print those debug
> > > messages to /dev/kmsg as well.
> > 
> > I'm not a fan of spamming dmesg from IGT and I'd prefer if you add this logging
> > to the kernel, 
> The idea was to simply log IGT actions, not to log kernel reactions on
> them which already happens.  Doing that from the kernel would probably
> require modifications to PCI sysfs handling or to sysfs in general.
> 
> If you see no benefits from that, let's drop this patch.

We (me & Petri) were thinking about doing something similar, but only
for the places where kernel logs are hard to correlate with the test
actions, to have those "synchronization points" between logs for key
operations.

The main reason was Chamelium - external board that simulates display
and can cause hotplug events to happen. Logging Chamelium operations in
dmesg would make any kind of bug assessment or troubleshooting much
easier - was that a phantom hotplug? or something that was triggered by
us? Have we started doing anything else before the link has settled?
What happened during DP FSM handling?

This is a very special case as we deal with an external board that
drives our HW through wires and layers of firmware and for sure there be
dragons.


Anyway, I would like to see us having a way of logging those "sync
points" into kmesg in igt_core, e.g. by creating _kmesg suffixed version
of log functions.

But I also see Michał's point - too frivolous logging just creates
noise, and we shouldn't double log - if something is already easy to
find in the kernel logs and the correlating test action to logs is not
too hard why should we add more noise?

As of the examples in this thread - I am not very familiar with the area
and I leave it up to you two to decide what would be helpful, what would
be unnecessary repetition and what would be better off logged in the
kernel.

TL;DR: Yes for logging things into kmesg, but we should be careful about
       what we log to not make the situation any worse.

-- 
Cheers,
Arek