linux-kernel - Re: [PATCH] drm/i915: Remove instructions to file a bug report.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87inr1qqz2.fsf@intel.com>
Date:   Sat, 03 Dec 2016 11:52:49 +0200
From:   Jani Nikula <jani.nikula@...ux.intel.com>
To:     Matt Turner <mattst88@...il.com>, intel-gfx@...ts.freedesktop.org
Cc:     Daniel Vetter <daniel.vetter@...el.com>,
        Mika Kuoppala <mika.kuoppala@...el.com>,
        Kenneth Graunke <kenneth@...tecape.org>,
        Mark Janes <mark.a.janes@...el.com>,
        linux-kernel@...r.kernel.org, Matt Turner <mattst88@...il.com>,
        "Argotti\, Yann" <yann.argotti@...el.com>,
        Chris Wilson <chris@...is-wilson.co.uk>
Subject: Re: [PATCH] drm/i915: Remove instructions to file a bug report.

On Sat, 03 Dec 2016, Matt Turner <mattst88@...il.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@...il.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