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 19:41:34 +0100 [thread overview]
Message-ID: <20131111184134.GG14978@phenom.ffwll.local> (raw)
In-Reply-To: <CA+gsUGSqVabR0GH5kQ+N3RLLjxU35oqjxHntX+mkgH87TqCsxw@mail.gmail.com>
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".
Checking dmesg in individual tests really doesn't make much sense imo and
needs to be somewhere where it's done for _all_ testcases. QA already has
that in their own testrunner infrastructure, unfortunately that's not
shared with developers so we get to invent a new wheel.
-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 18:41 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 [this message]
2013-11-11 18:54 ` Paulo Zanoni
2013-11-11 21:10 ` Daniel Vetter
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=20131111184134.GG14978@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