On Thu, Nov 19, 2015 at 10:38 AM, Daniel Vetter <[email protected]> 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 <[email protected]> >> > > Cc: Chris Wilson <[email protected]> >> > > Cc: Damien Lespiau <[email protected]> >> > > Signed-off-by: Joonas Lahtinen <[email protected]> >> > >> > 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 <[email protected]>
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? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
