[Intel-gfx] [PATCH i-g-t] Add dmesg capture and dumping to tests and a test for it.

[Joonas Lahtinen]

On pe, 2015-11-20 at 11:34 +0000, Chris Wilson wrote:
> On Fri, Nov 20, 2015 at 01:22:51PM +0200, Joonas Lahtinen wrote:
> > On to, 2015-11-19 at 10:41 +0100, Daniel Vetter wrote:
> > > On Thu, Nov 19, 2015 at 10:38 AM, Daniel Vetter <daniel at ffwll.ch>
> > > wrote:
> > > > On Wed, Nov 18, 2015 at 05:32:59PM +0000, Chris Wilson wrote:
> > > > > On Wed, Nov 18, 2015 at 04:44:20PM +0100, Daniel Vetter
> > > > > wrote:
> > > > > > On Mon, Nov 16, 2015 at 03:22:23PM +0200, Joonas Lahtinen
> > > > > > wrote:
> > > > > > > Cc: Thomas Wood <thomas.wood at intel.com>
> > > > > > > Cc: Chris Wilson <chris at chris-wilson.co.uk>
> > > > > > > Cc: Damien Lespiau <damien.lespiau at intel.com>
> > > > > > > Signed-off-by: Joonas Lahtinen <
> > > > > > > joonas.lahtinen at linux.intel.com>
> > > > > > 
> > > > > > Given that we have all that in piglit already the commit
> > > > > > message is a bit
> > > > > > thin on justification. Why do we need this in igt too? How
> > > > > > does
> > > > > > this
> > > > > > interact with the piglit dmesg capture?
> > > > > 
> > > > > It's doesn't interfere with anyone else parsing kmsg/dmesg
> > > > > for
> > > > > themselves, but it adds very useful functionality to
> > > > > standalone
> > > > > igt.
> > > > > Which to me is significantly more valuable and I have been
> > > > > patching it
> > > > > into igt for over a year and wished it was taken more
> > > > > seriously
> > > > > given
> > > > > the number of incorrect bug reports generated.
> > > > 
> > > > Ah, the "It doesn't interfere ..." is the crucial part I
> > > > missed, I
> > > > didn't
> > > > know you could read dmesg in parallel without eating message
> > > > for
> > > > other
> > > > consumers. Jonaas, with the above used as commit message (or
> > > > something
> > > > similar) this is Acked-by: Daniel Vetter <
> > > > daniel.vetter at ffwll.ch>
> > > 
> > > Ok, I need to retract this. piglit does some dmesg filtering, how
> > > do
> > > we make sure these two definitions of what's considered failing
> > > dmesg
> > > noise match up?
> > 
> > I would move that decision to I-G-T, and just let piglit interpret
> > the
> > FAIL (KMSG) status. Currently my proposal is that any LOG_NOTICE or
> > higher priority message (in any facility) causes the test to fail.
> 
> Not NOTICE. WARN or above, since NOTICE is a "normal but significant
> condition". I have been pushing for us to use NOTICE more
> effectively,
> many of our ERRORs can just be NOTICEs since we are able to take
> corrective action (and we expect to take such action).
> -Chris
> 

We could have two FD's open on /dev/kmsg, we'd first scan out just the
message priorities and then at convenient display time all the messages
if the warn or above priority is in the log.

It's not ideal, but doesn't require allocating arbitary amount of
buffers.

Regards, Joonas

-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation