From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Mika Kuoppala <mika.kuoppala@intel.com>,
Kenneth Graunke <kenneth@whitecape.org>,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH] drm/i915: Reinstate error level message for non-simulated gpu hangs
Date: Wed, 1 Oct 2014 10:13:00 +0200 [thread overview]
Message-ID: <20141001081300.GJ12343@phenom.ffwll.local> (raw)
In-Reply-To: <20141001062839.GP19278@nuc-i3427.alporthouse.com>
On Wed, Oct 01, 2014 at 07:28:39AM +0100, Chris Wilson wrote:
> On Wed, Oct 01, 2014 at 01:04:19AM +0200, Daniel Vetter wrote:
> > This seems to have been accidentally lost in
> >
> > commit be62acb4cce1389a28296852737e3917d9cc5b25
> > Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> > Date: Fri Aug 30 16:19:28 2013 +0300
> >
> > drm/i915: ban badly behaving contexts
> >
> > Without this real gpu hangs only log output at info level, which gets
> > filtered away by piglit's testrunner.
>
> A successful GPU hang is not an error. Might be a warn or a notice, but
> it certainly isn't a driver error.
Well not of the kernel driver, but might very well be a bug in the
userspace driver. With this piglit marks tests that hung the gpu as
dmesg-fail, without this they might even pass. Ken raised this on irc and
I agree that it's a must-have feature for developers that their testsuite
can tell them when stuff broke. Provding this some other way is a lot more
work and imo should be done in a separate patch, this here is just the
minimal fix for this regression.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-10-01 8:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-30 23:04 [PATCH] drm/i915: Reinstate error level message for non-simulated gpu hangs Daniel Vetter
2014-10-01 6:28 ` Chris Wilson
2014-10-01 8:13 ` Daniel Vetter [this message]
2014-10-01 8:19 ` Chris Wilson
2014-10-01 8:29 ` Daniel Vetter
2014-10-01 8:52 ` Kenneth Graunke
2014-10-01 9:10 ` Chris Wilson
2014-10-01 9:28 ` Daniel Vetter
2014-10-01 9:37 ` Chris Wilson
2014-10-01 9:41 ` Daniel Vetter
2014-10-01 9:50 ` Chris Wilson
2014-10-01 9:32 ` Daniel Vetter
2014-10-01 12:03 ` Daniel Vetter
2014-10-01 13:54 ` Chris Wilson
2014-10-01 14:40 ` Mika Kuoppala
[not found] <1412118259-4860-1-git-send-email-daniel.vetter@ffwll.c>
2014-10-01 9:15 ` 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=20141001081300.GJ12343@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=kenneth@whitecape.org \
--cc=mika.kuoppala@intel.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