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

[Chris Wilson <chris@chris-wilson.co.uk>]

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@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@intel.com>
> > > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > > Cc: Damien Lespiau <damien.lespiau@intel.com>
> > > > > > Signed-off-by: Joonas Lahtinen <
> > > > > > joonas.lahtinen@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@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

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx