From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
intel-gfx@lists.freedesktop.org, Ben Widawsky <ben@bwidawsk.net>
Subject: Re: [PATCH] drm/i915: Decouple GPU error reporting from ring initialisation
Date: Fri, 24 Jan 2014 14:06:12 +0200 [thread overview]
Message-ID: <20140124120612.GC9454@intel.com> (raw)
In-Reply-To: <20140124115521.GE25529@nuc-i3427.alporthouse.com>
On Fri, Jan 24, 2014 at 11:55:21AM +0000, Chris Wilson wrote:
> On Fri, Jan 24, 2014 at 01:50:25PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 23, 2014 at 09:49:43PM +0000, Chris Wilson wrote:
> > > Currently we report through our error state only the rings that have
> > > been initialised (as detected by ring->obj). This check is done after
> > > the GPU reset and ring re-initialisation, which means that the software
> > > state may not be the same as when we captured the hardware error and we
> > > may not print out any of the vital information for debugging the hang.
> > >
> > > This (and the implied object leak) is a regression from
> > >
> > > commit 3d57e5bd1284f44e325f3a52d966259ed42f9e05
> > > Author: Ben Widawsky <ben@bwidawsk.net>
> > > Date: Mon Oct 14 10:01:36 2013 -0700
> > >
> > > drm/i915: Do a fuller init after reset
> > >
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: Ben Widawsky <ben@bwidawsk.net>
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > drivers/gpu/drm/i915/i915_gpu_error.c | 19 +++++++++++++------
> > > 2 files changed, 14 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > > index c45cbbecd66a..64a1aca7804d 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -334,6 +334,7 @@ struct drm_i915_error_state {
> > > struct timeval time;
> > >
> > > struct drm_i915_error_ring {
> > > + int valid;
> >
> > bool
>
> in a struct? I tend to think it leads to laziness not to coalesce them
> into bitfields.
bool valid:1; then ;)
>
> > > - obj = error->ring[i].ctx;
> > > - if (obj) {
> > > + if ((obj = error->ring[i].ctx)) {
> >
> > Unrelated change. Although it does make this more consistent w/ the
> > surrouding code. But I admit to not being a fan of assignments inside
> > if statements.
>
> The inconsistency was uglier.
>
> > > err_printf(m, "%s --- HW Context = 0x%08x\n",
> > > dev_priv->ring[i].name,
> > > obj->gtt_offset);
> > > @@ -826,11 +827,17 @@ static void i915_gem_record_rings(struct drm_device *dev,
> > > struct drm_i915_error_state *error)
> > > {
> > > struct drm_i915_private *dev_priv = dev->dev_private;
> > > - struct intel_ring_buffer *ring;
> > > struct drm_i915_gem_request *request;
> > > int i, count;
> > >
> > > - for_each_ring(ring, dev_priv, i) {
> > > + for (i = 0; i < I915_NUM_RINGS; i++) {
> > > + struct intel_ring_buffer *ring = &dev_priv->ring[i];
> > > +
> > > + if (ring->dev == NULL)
> > > + continue;
> > > +
> > > + error->ring[i].valid = true;
> > > +
> >
> > The code here runs before the reset, and it would actually oops if
> > ring->obj==NULL, so using for_each_ring() here looks appropriate.
>
> No, we need to record that ring->obj is NULL, especially if the ring
> registers are still set...
OK so we just need to actually fix the scratch.obj==NULL case, and then
I guess it's fine.
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2014-01-24 12:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-23 21:49 [PATCH] drm/i915: Decouple GPU error reporting from ring initialisation Chris Wilson
2014-01-24 11:50 ` Ville Syrjälä
2014-01-24 11:55 ` Chris Wilson
2014-01-24 12:06 ` Ville Syrjälä [this message]
2014-01-27 13:52 ` Chris Wilson
2014-01-27 14:05 ` Ville Syrjälä
2014-01-27 16:13 ` [Intel-gfx] " 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=20140124120612.GC9454@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=ben@bwidawsk.net \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/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