<div dir="ltr">I believe it would be a good idea to modify the core behavior of the dmesg flag to make sure that it can only be enabled when you are not running in concurrent. This is because the wrong test could be flagged as causing the dmesg message when it should be another test. This only has to deal with the effects of synchronization.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 15, 2013 at 12:42 PM, Marek Olšák <span dir="ltr"><<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Why not to have both?<br>
<span class="HOEnZb"><font color="#888888"><br>
Marek<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Fri, Nov 15, 2013 at 7:33 PM, Dylan Baker <<a href="mailto:baker.dylan.c@gmail.com">baker.dylan.c@gmail.com</a>> wrote:<br>
> On Friday, November 15, 2013 06:28:41 PM Marek Olšák wrote:<br>
>> I'll gladly type --dmesg=radeon.<br>
>><br>
>> I have my own script for running piglit anyway, which calls piglit-run<br>
>> and piglit-summary-html, and the result and summary directories are<br>
>> named $(date)_$(time)_$(GLrenderer)_$(test_filters), and it can do a<br>
>> couple of other things.<br>
>><br>
>> Marek<br>
>><br>
>> On Fri, Nov 15, 2013 at 5:26 PM, Dylan Baker <<a href="mailto:baker.dylan.c@gmail.com">baker.dylan.c@gmail.com</a>><br>
> wrote:<br>
>> > On Friday, November 15, 2013 10:42:11 AM Daniel Vetter wrote:<br>
>> >> On Thu, Nov 14, 2013 at 10:35:03AM -0800, Dylan Baker wrote:<br>
>> >> > On Thursday, November 14, 2013 05:34:38 PM Daniel Vetter wrote:<br>
>> >> > > On Thu, Nov 14, 2013 at 08:04:20AM -0800, Dylan Baker wrote:<br>
>> >> > > > On Thursday, November 14, 2013 02:52:41 PM Daniel Vetter wrote:<br>
>> >> > > > > On Tue, Nov 12, 2013 at 07:54:01AM -0800, Dylan Baker wrote:<br>
>> >> > > > > > This gives the dmesg class lists of statuses that will make a<br>
>> >> > > > > > test<br>
>> >> > > > > > a<br>
>> >> > > > > > warn or a fail, it includes a few basic checks, namely i915<br>
>> >> > > > > > errors<br>
>> >> > > > > > and<br>
>> >> > > > > > that tests have not segfaulted.<br>
>> >> > > > > ><br>
>> >> > > > > > Signed-off-by: Dylan Baker <<a href="mailto:baker.dylan.c@gmail.com">baker.dylan.c@gmail.com</a>><br>
>> >> > > > > > ---<br>
>> >> > > > > ><br>
>> >> > > > > > framework/dmesg.py | 36<br>
>> >> > > > > > ++++++++++++++++++++++++++++++++----<br>
>> >> > > > > > framework/exectest.py | 22 +++++++++++++++-------<br>
>> >> > > > > > 2 files changed, 47 insertions(+), 11 deletions(-)<br>
>> >> > > > > ><br>
>> >> > > > > > diff --git a/framework/dmesg.py b/framework/dmesg.py<br>
>> >> > > > > > index 9a23c14..edbea88 100644<br>
>> >> > > > > > --- a/framework/dmesg.py<br>
>> >> > > > > > +++ b/framework/dmesg.py<br>
>> >> > > > > > @@ -22,6 +22,7 @@<br>
>> >> > > > > ><br>
>> >> > > > > > """ Module implementing classes for reading posix dmesg """<br>
>> >> > > > > ><br>
>> >> > > > > > import os<br>
>> >> > > > > ><br>
>> >> > > > > > +import re<br>
>> >> > > > > ><br>
>> >> > > > > > import subprocess<br>
>> >> > > > > > from threads import synchronized_self<br>
>> >> > > > > ><br>
>> >> > > > > > @@ -29,8 +30,10 @@ __all__ = ['Dmesg']<br>
>> >> > > > > ><br>
>> >> > > > > > # plain text list of statuses to be considered either a warn<br>
>> >> > > > > > or a<br>
>> >> > > > > > fail,<br>
>> >> > > > > > any<br>
>> >> > > > > > # statuses not on this list will simply be ignored.<br>
>> >> > > > > ><br>
>> >> > > > > > -WARN_STATUSES = []<br>
>> >> > > > > > -FAIL_STATUSES = []<br>
>> >> > > > > > +WARN_STATUSES = ['segfault']<br>
>> >> > > > > > +FAIL_STATUSES = ['\[drm:.*\] \*ERROR\*',<br>
>> >> > > > > > + '\[drm\] stuck on [a-zA-Z]* ring',<br>
>> >> > > > > > + '\[drm\] GPU crash dump saved']<br>
>> >> > > > ><br>
>> >> > > > > I think now that we filter out all the info/debug noise maybe we<br>
>> >> > > > > could<br>
>> >> > > > > go<br>
>> >> > > > > the other direction and blacklist a few of the remaining things<br>
>> >> > > > > from<br>
>> >> > > > > the<br>
>> >> > > > > core kernel we don't care about. E.g.<br>
>> >> > > > ><br>
>> >> > > > > [ 3867.022895] gem_evict_every (2671) used greatest stack depth:<br>
>> >> > > > > 2216<br>
>> >> > > > > bytes<br>
>> >> > > > > left<br>
>> >> > > > ><br>
>> >> > > > > is a warn level message, but I don't care one bit about it (as<br>
>> >> > > > > long<br>
>> >> > > > > as<br>
>> >> > > > > it<br>
>> >> > > > > doesn't approach 0). But there's other warn level stuff which is<br>
>> >> > > > > fairly<br>
>> >> > > > > interesting.<br>
>> >> > > > ><br>
>> >> > > > > Just something to throw out there, I'm not sure what the best way<br>
>> >> > > > > would<br>
>> >> > > > > be<br>
>> >> > > > > to integrate dmesg reporting for piglit in general.<br>
>> >> > > > > -Daniel<br>
>> >> > > ><br>
>> >> > > > My personal problem with the dmesg code we have now (and with<br>
>> >> > > > *just*<br>
>> >> > > > blacklisting) is that I have an alps touchpad, it spams dmesg about<br>
>> >> > > > 10<br>
>> >> > > > times a minute, so I can't use dmesg reporting because of the<br>
>> >> > > > massive<br>
>> >> > > > number of false positives; we could use some combination of<br>
>> >> > > > blacklisting<br>
>> >> > > > and whitelisting however.<br>
>> >> > ><br>
>> >> > > That sounds like we need a piglit cmdline option to supply a regex to<br>
>> >> > > filter out crap like that ... Or is the alps touchpad driver so bad<br>
>> >> > > there's not even a regex we could match it all against?<br>
>> >> > > -Daniel<br>
>> >> ><br>
>> >> > My concern is more that trying to filter out things we don't want seems<br>
>> >> > like an uphill battle that will become expensive quickly. First it's my<br>
>> >> > touchpad, then it's so and so's usb, and so on. I'm giong to ask some<br>
>> >> > of<br>
>> >> > the mesa guys here in the office to weigh in with their thoughts, since<br>
>> >> > they're all around today, snice I'm basing interest on one developer's<br>
>> >> > opinions.<br>
>> >><br>
>> >> That's kinda what the cmdline would be for, to get rid of<br>
>> >> machine-specific<br>
>> >> stuff like your touchpad. I'm retesting igt on all the machines I have<br>
>> >> here right now, and thus far the stack usage warning is the only offender<br>
>> >> I've seend which wasn't a genuine issue. But yeah, more input should<br>
>> >> definitely help.<br>
>> >> -Daniel<br>
>> ><br>
>> > So if I'm understanding correctly, you're asking users to craft regex on<br>
>> > the commandline every time they run piglit? that sounds like a nightmare.<br>
><br>
> Okay, now I'm confused. Are we debating include regex on the command line or<br>
> exclude regex on the command line?<br>
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Piglit mailing list<br>
<a href="mailto:Piglit@lists.freedesktop.org">Piglit@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/piglit" target="_blank">http://lists.freedesktop.org/mailman/listinfo/piglit</a><br>
</div></div></blockquote></div><br></div>