All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH] drm/i915: Stop gathering error states for CS	error interrupts
Date: Tue, 04 Nov 2014 17:02:57 +0200	[thread overview]
Message-ID: <87egtjdn4u.fsf@intel.com> (raw)
In-Reply-To: <1415112742-24955-1-git-send-email-daniel.vetter@ffwll.ch>

On Tue, 04 Nov 2014, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> There's quite a few bug reports with error states where the error
> reasons makes just about no sense at all. Like dying on tlbs for a
> display plane that's not even there. Also users don't really report a
> lot of bad side effects generally, just the error states.
>
> Furthermore we don't even enable these interrupts any more on gen5+
> (though the handling code is still there). So this mostly concerns old
> platforms.
>
> Given all that lets make our lives a bit easier and stop capturing
> error states, in the hopes that we can just ignore them. In case
> that's not true and the gpu indeed dies the hangcheck should
> eventually kick in. And I've left some debug log in to make this case
> noticeble. Referenced bug is just an example.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=82095
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 25 +++++++------------------
>  1 file changed, 7 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 318a6a0724d0..2f78764cb215 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1319,10 +1319,8 @@ static void snb_gt_irq_handler(struct drm_device *dev,
>  
>  	if (gt_iir & (GT_BLT_CS_ERROR_INTERRUPT |
>  		      GT_BSD_CS_ERROR_INTERRUPT |
> -		      GT_RENDER_CS_MASTER_ERROR_INTERRUPT)) {
> -		i915_handle_error(dev, false, "GT error interrupt 0x%08x",
> -				  gt_iir);
> -	}
> +		      GT_RENDER_CS_MASTER_ERROR_INTERRUPT))
> +		DRM_DEBUG("Command parser error, gt_iir 0x%08x", gt_iir);

\n missing all around.

BR,
Jani.

>  
>  	if (gt_iir & GT_PARITY_ERROR(dev))
>  		ivybridge_parity_error_irq_handler(dev, gt_iir);
> @@ -1715,11 +1713,8 @@ static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32 pm_iir)
>  		if (pm_iir & PM_VEBOX_USER_INTERRUPT)
>  			notify_ring(dev_priv->dev, &dev_priv->ring[VECS]);
>  
> -		if (pm_iir & PM_VEBOX_CS_ERROR_INTERRUPT) {
> -			i915_handle_error(dev_priv->dev, false,
> -					  "VEBOX CS error interrupt 0x%08x",
> -					  pm_iir);
> -		}
> +		if (pm_iir & PM_VEBOX_CS_ERROR_INTERRUPT)
> +			DRM_DEBUG("Command parser error, pm_iir 0x%08x", pm_iir);
>  	}
>  }
>  
> @@ -3744,9 +3739,7 @@ static irqreturn_t i8xx_irq_handler(int irq, void *arg)
>  		 */
>  		spin_lock(&dev_priv->irq_lock);
>  		if (iir & I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT)
> -			i915_handle_error(dev, false,
> -					  "Command parser error, iir 0x%08x",
> -					  iir);
> +			DRM_DEBUG("Command parser error, iir 0x%08x", iir);
>  
>  		for_each_pipe(dev_priv, pipe) {
>  			int reg = PIPESTAT(pipe);
> @@ -3929,9 +3922,7 @@ static irqreturn_t i915_irq_handler(int irq, void *arg)
>  		 */
>  		spin_lock(&dev_priv->irq_lock);
>  		if (iir & I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT)
> -			i915_handle_error(dev, false,
> -					  "Command parser error, iir 0x%08x",
> -					  iir);
> +			DRM_DEBUG("Command parser error, iir 0x%08x", iir);
>  
>  		for_each_pipe(dev_priv, pipe) {
>  			int reg = PIPESTAT(pipe);
> @@ -4156,9 +4147,7 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)
>  		 */
>  		spin_lock(&dev_priv->irq_lock);
>  		if (iir & I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT)
> -			i915_handle_error(dev, false,
> -					  "Command parser error, iir 0x%08x",
> -					  iir);
> +			DRM_DEBUG("Command parser error, iir 0x%08x", iir);
>  
>  		for_each_pipe(dev_priv, pipe) {
>  			int reg = PIPESTAT(pipe);
> -- 
> 2.1.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2014-11-04 15:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-04 14:52 [PATCH] drm/i915: Stop gathering error states for CS error interrupts Daniel Vetter
2014-11-04 15:02 ` Jani Nikula [this message]
2014-11-05  8:35 ` Chris Wilson
2014-11-05  9:56   ` Daniel Vetter
2014-11-24 20:57     ` Daniel Vetter
2014-11-24 21:42       ` Chris Wilson

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=87egtjdn4u.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --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 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.