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

Daniel Vetter daniel at ffwll.ch
Thu Nov 19 01:41:25 PST 2015


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?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the Intel-gfx mailing list