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
next prev parent 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