[Piglit] RFC enhance dmesg handling in piglit

[Daniel Vetter]

On Tue, Nov 12, 2013 at 10:32:21PM +0100, Marek Olšák wrote:
> Do I have to define my own regexp? What if I don't want to filter
> anything, i.e. '.*'?

I was more talking about the filtering out of debug/info level dmesg
lines. I.e. the little hack I've posted yesterday:

http://lists.freedesktop.org/archives/piglit/2013-November/008361.html

For igt I want everything else counted towards dmesg-fail really.
-Daniel

> 
> Marek
> 
> On Tue, Nov 12, 2013 at 8:07 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> > On Tue, Nov 12, 2013 at 7:53 PM, Dylan Baker <baker.dylan.c at gmail.com> wrote:
> >> On Tuesday, November 12, 2013 07:21:50 PM Daniel Vetter wrote:
> >>> On Tue, Nov 12, 2013 at 07:53:58AM -0800, Dylan Baker wrote:
> >>> > This series cleans up the dmesg handlingin piglit by implementing a
> >>> > module with two classes, one for reading dmesg, and the other that acts
> >>> > as a dummy class on non-posix systems, this allows dmesg to just always
> >>> > be turned on all the time.
> >>> >
> >>> > Secondly this new dmesg class has the ability to filter dmesg entries,
> >>> > searching for specific regular expressions and classifying them as
> >>> > either 'warns' or 'fails'.
> >>> >
> >>> > Currently the filtering is fairly simply, and I expect to have at least
> >>> > one more iteration of these patches with more enries for dmesg. It
> >>> > curretly as an example marks any test the segfaults as a 'warn', and
> >>> > searches for some entries emmitted by the i915 driver and marks them
> >>> > 'fail'.
> >>>
> >>> Looks like we're colliding a bit here, cool ;-)
> >>>
> >>> Essentially for i-g-t testcases the rule is that everything in dmesg which
> >>> isn't at the debug/info level should make the test fail. Otoh if the tests
> >>> succeeds and there's only new info/debug stuff in dmesg, then the result
> >>> state shouldn't be set to 'warn'. This is because a lot of our tests are
> >>> expected to generate info level messages (e.g. simulated gpu hangs or
> >>> module reload). And we often enable full drm debugging when running tests,
> >>> which spews a lot.
> >>>
> >>> So either we need to capture the raw dmesg output to be able to pattern
> >>> match log-levels (dmesg -r). Or we do the cheap trick I've done in the
> >>> patch submitted yesterday of simply filtering out unwanted levels at the
> >>> source.
> >>>
> >>> But overall I really want dmesg capture support by default for igt tests.
> >>> -Daniel
> >>
> >> So it sounds like the right solution would be to have a set of filters that
> >> make sense for piglit's "native" tests, and then allow external tests to
> >> overwrite the filters before calling dmesg. Does that sound like a workable
> >> solution?
> >>
> >> I actually assumed that your dmesg filtering would land, and I'd rebase on top
> >> of it.
> >
> > If Marek is ok with the filtering by default then I think we can go
> > ahead with that. But if other people are also interested in filtering
> > dmesg using the log levels then maybe we should switch to capturing
> > them first.
> > -Daniel
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch