All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Tomas Elf <tomas.elf@intel.com>,
	Mika Kuoppala <mika.kuoppala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH] drm/i915: Reset request handling for gen8+
Date: Thu, 18 Jun 2015 16:58:06 +0200	[thread overview]
Message-ID: <20150618145806.GG7752@phenom.ffwll.local> (raw)
In-Reply-To: <20150618114255.GK24012@nuc-i3427.alporthouse.com>

On Thu, Jun 18, 2015 at 12:42:55PM +0100, Chris Wilson wrote:
> On Thu, Jun 18, 2015 at 12:18:39PM +0100, Tomas Elf wrote:
> > My point was more along the lines of bailing out if the reset
> > request fails and not return an error message but simply keep track
> > of the number of times we've attempted the reset request. By not
> > returning an error we would allow more subsequent hang detections to
> > happen (since the hang is still there), which would end up in the
> > same reset request in the future. If the reset request would fail
> > more times we would simply increment the counter and at one point we
> > would decide that we've had too many unsuccessful reset request
> > attempts and simply go ahead with the reset anyway and if the reset
> > would fail we would return an error at that point in time, which
> > would result in a terminally wedged state. But, yeah, I can see why
> > we shouldn't do this.
> 
> Skipping to the middle!
> 
> I understand the merit in trying the reset a few times before giving up,
> it would just need a bit of restructuring to try the reset before
> clearing gem state (trivial) and requeueing the hangcheck. I am just
> wary of feature creep before we get stuck into TDR, which promises to
> change how we think about resets entirely.

My maintainer concern here is always that we should err on the side of not
killing the machine. If the reset failed, or if the gpu reinit failed then
marking the gpu as wedged has historically been the safe option. The
system will still run, display mostly works and there's a reasonable
chance you can gather debug data.

We do have i915.reset to disable the reset for these cases, but it's
always a nuisance to have to resort to that.
-Daneil
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-06-18 14:55 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-16 13:39 [PATCH 1/1] drm/i915: Reset request handling for gen9+ Mika Kuoppala
2015-06-16 14:09 ` Chris Wilson
2015-06-16 17:10 ` Chris Wilson
2015-06-16 20:15   ` Tomas Elf
2015-06-17  6:33     ` Mika Kuoppala
2015-06-16 19:57 ` Tomas Elf
2015-06-17 12:35 ` [PATCH] drm/i915: Reset request handling for gen8+ Mika Kuoppala
2015-06-18  8:36   ` Mika Kuoppala
2015-06-18  8:50     ` Chris Wilson
2015-06-18  9:51       ` Mika Kuoppala
2015-06-18 10:03         ` Chris Wilson
2015-06-18 10:22           ` Mika Kuoppala
2015-06-18 15:00             ` Daniel Vetter
2015-06-18 10:11         ` Tomas Elf
2015-06-18 10:31           ` Mika Kuoppala
2015-06-18 10:36           ` Chris Wilson
2015-06-18 11:18             ` Tomas Elf
2015-06-18 11:42               ` Chris Wilson
2015-06-18 14:58                 ` Daniel Vetter [this message]
2015-06-19 16:30                   ` Chris Wilson
2015-06-22 12:50                     ` 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=20150618145806.GG7752@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mika.kuoppala@linux.intel.com \
    --cc=tomas.elf@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.