[Piglit] RFC enhance dmesg handling in piglit

[Marek Olšák]

Sounds good.

Marek

On Tue, Nov 12, 2013 at 10:55 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> 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