public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Paulo Zanoni <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH 2/2] tests: add kms_edp_vdd_race
Date: Mon, 11 Nov 2013 22:10:38 +0100	[thread overview]
Message-ID: <20131111211038.GI14978@phenom.ffwll.local> (raw)
In-Reply-To: <CA+gsUGT8G80W3tFmMs8VUwPT5Lxr-xzYrfGRzv8_o5WZZbvm8Q@mail.gmail.com>

On Mon, Nov 11, 2013 at 04:54:32PM -0200, Paulo Zanoni wrote:
> 2013/11/11 Daniel Vetter <daniel@ffwll.ch>:
> > On Mon, Nov 11, 2013 at 04:25:36PM -0200, Paulo Zanoni wrote:
> >> 2013/11/11 Daniel Vetter <daniel@ffwll.ch>:
> >> > On Mon, Nov 11, 2013 at 03:06:10PM -0200, Paulo Zanoni wrote:
> >> >> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
> >> >>
> >> >> We recently fixed a bug where it was impossible to do I2C transactions
> >> >> on eDP panels when they were disabled. Now it should be possible to do
> >> >> these transactions when the panel is disabled, but there's a race
> >> >> condition that triggers dmesg errors if we try do do the I2C
> >> >> transactions and set a mode on the panel at the same time. This
> >> >> program should reproduce this bug and check dmesg for errors.
> >> >>
> >> >> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> >> >
> >> > Like I've said in the previous mail I think the generic dmesg error
> >> > checking should be somewhere generic (and probably in piglit). Otherwise
> >> > the test looks good. And the naming also matches the new convention ;-)
> >>
> >> Then this test will always give a SUCCESS. Not really what I wanted :(
> >
> > It's not the only one. We have tests that only annoy the in-kernel debug
> > features like lockdep, object use-after-free and other stuff. Or all the
> > WARN backtraces from testdisplay. And very often they all "succeed".
> 
> And that's the problem I'm trying to solve. We have a solution, it's
> useful not just for me - you just gave examples of where it would be
> useful too -, yet, IMHO, you still didn't give a good technical reason
> on why you're rejecting it.
> 
> >
> > Checking dmesg in individual tests really doesn't make much sense imo
> 
> Well, IMHO it makes a lot of sense. It's even helping me write code,
> as I already explained.
> 
> 
> > and
> > needs to be somewhere where it's done for _all_ testcases.
> 
> My code is not preventing that. In fact, I think it's helping us get
> to that point.
> 
> 
> > QA already has
> > that in their own testrunner infrastructure, unfortunately that's not
> > shared with developers so we get to invent a new wheel.
> 
> I just proposed these new wheels...

Ok, lazy me finally got around to just doing it. I've sent 2 patches to
the piglit mailing list which enable dmesg checking for igt runs by
default in less than 5 lines of code. For all tests, at the subtest
granularity.

Imo this simplicity a technical reason to do it in piglit ;-)

That leaves us with your use-case of very fine-grained checking of dmesg
errors within a testcase. tbh I'm not really sold on this being that
useful, but I'd be ok with merging the helper code if you convinced it's a
great idea. One thing though which could be improved is the cleanup - imo
it's much simpler to just have an atexit handler for such helpers.

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

  reply	other threads:[~2013-11-11 21:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-11 17:06 [PATCH 1/2] drmtest: introduce kmsg_error functions Paulo Zanoni
2013-11-11 17:06 ` [PATCH 2/2] tests: add kms_edp_vdd_race Paulo Zanoni
2013-11-11 18:15   ` Daniel Vetter
2013-11-11 18:25     ` Paulo Zanoni
2013-11-11 18:41       ` Daniel Vetter
2013-11-11 18:54         ` Paulo Zanoni
2013-11-11 21:10           ` Daniel Vetter [this message]
2013-11-11 18:02 ` [PATCH 1/2] drmtest: introduce kmsg_error functions Daniel Vetter
2013-11-11 18:18   ` Paulo Zanoni
2013-11-11 18:48     ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131111211038.GI14978@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=paulo.r.zanoni@intel.com \
    --cc=przanoni@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox