Sounds good. Marek
On Tue, Nov 12, 2013 at 10:55 PM, Daniel Vetter <[email protected]> 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 <[email protected]> wrote: >> > On Tue, Nov 12, 2013 at 7:53 PM, Dylan Baker <[email protected]> >> > 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 _______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
