linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Matt Turner <mattst88@gmail.com>, intel-gfx@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	Mika Kuoppala <mika.kuoppala@intel.com>,
	Kenneth Graunke <kenneth@whitecape.org>,
	Mark Janes <mark.a.janes@intel.com>,
	linux-kernel@vger.kernel.org, Matt Turner <mattst88@gmail.com>,
	"Argotti\, Yann" <yann.argotti@intel.com>,
	Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [PATCH] drm/i915: Remove instructions to file a bug report.
Date: Sat, 03 Dec 2016 11:52:49 +0200	[thread overview]
Message-ID: <87inr1qqz2.fsf@intel.com> (raw)
In-Reply-To: <1480726985-12762-1-git-send-email-mattst88@gmail.com>

On Sat, 03 Dec 2016, Matt Turner <mattst88@gmail.com> wrote:
> From these instructions, users assume that /sys/class/drm/card0/error
> contains all the information a developer needs to diagnose and fix a GPU
> hang.
>
> In fact it doesn't, and we have no tools for solving them (other than
> stabbing in the dark). Most of the time the error state itself isn't
> even useful because it just shows a hang on a PIPE_CONTROL or similar.
>
> Until a time when the error state contains enough information to
> actually solve a hang, stop telling users to file unsolvable bugs, and
> instead rely on users who know where and how to file a good bug report
> to find their own way there.
>
> Signed-off-by: Matt Turner <mattst88@gmail.com>
> ---
> Maybe now's a good time to discuss what *would* be useful to put in the
> error state for debugging hangs. The currently executing shader program
> would be a great place to start.

I'm wondering why we're getting this patch now, and my guess is that
it's because we have been reassigning the related bugs to Mesa more
actively lately. Is that the case?

IIUC the bug reports are useful for us when it's a kernel bug, but less
useful for you when it's a Mesa bug. And you'd rather have fewer
incoming bugs that you think are unsolvable with the information at
hand.

Sounds like a bug workflow issue between drm/i915 and Mesa to be ironed
out.


BR,
Jani.


>
>  drivers/gpu/drm/i915/i915_gpu_error.c | 11 -----------
>  1 file changed, 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 334f15d..8ddca7b 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -1431,7 +1431,6 @@ void i915_capture_error_state(struct drm_i915_private *dev_priv,
>  			      u32 engine_mask,
>  			      const char *error_msg)
>  {
> -	static bool warned;
>  	struct drm_i915_error_state *error;
>  	unsigned long flags;
>  
> @@ -1475,16 +1474,6 @@ void i915_capture_error_state(struct drm_i915_private *dev_priv,
>  		i915_error_state_free(&error->ref);
>  		return;
>  	}
> -
> -	if (!warned) {
> -		DRM_INFO("GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.\n");
> -		DRM_INFO("Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel\n");
> -		DRM_INFO("drm/i915 developers can then reassign to the right component if it's not a kernel issue.\n");
> -		DRM_INFO("The gpu crash dump is required to analyze gpu hangs, so please always attach it.\n");
> -		DRM_INFO("GPU crash dump saved to /sys/class/drm/card%d/error\n",
> -			 dev_priv->drm.primary->index);
> -		warned = true;
> -	}
>  }
>  
>  void i915_error_state_get(struct drm_device *dev,

-- 
Jani Nikula, Intel Open Source Technology Center

  parent reply	other threads:[~2016-12-03  9:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-03  1:03 [PATCH] drm/i915: Remove instructions to file a bug report Matt Turner
2016-12-03  1:26 ` Matt Turner
2016-12-03  8:57 ` [Intel-gfx] " Chris Wilson
2016-12-03  9:52 ` Jani Nikula [this message]
2016-12-06  0:55   ` Matt Turner
2016-12-07 16:09     ` [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=87inr1qqz2.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=kenneth@whitecape.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.a.janes@intel.com \
    --cc=mattst88@gmail.com \
    --cc=mika.kuoppala@intel.com \
    --cc=yann.argotti@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;
as well as URLs for NNTP newsgroup(s).