From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752258AbcLFA4K (ORCPT ); Mon, 5 Dec 2016 19:56:10 -0500 Received: from mail-yw0-f179.google.com ([209.85.161.179]:33564 "EHLO mail-yw0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751201AbcLFA4J (ORCPT ); Mon, 5 Dec 2016 19:56:09 -0500 MIME-Version: 1.0 In-Reply-To: <87inr1qqz2.fsf@intel.com> References: <1480726985-12762-1-git-send-email-mattst88@gmail.com> <87inr1qqz2.fsf@intel.com> From: Matt Turner Date: Mon, 5 Dec 2016 16:55:47 -0800 Message-ID: Subject: Re: [PATCH] drm/i915: Remove instructions to file a bug report. To: Jani Nikula Cc: "intel-gfx@lists.freedesktop.org" , Daniel Vetter , Mika Kuoppala , Kenneth Graunke , Mark Janes , LKML , "Argotti, Yann" , Chris Wilson Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Dec 3, 2016 at 1:52 AM, Jani Nikula wrote: > On Sat, 03 Dec 2016, Matt Turner 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 >> --- >> 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? No, it's simply because I spent a week going through Bugzilla and realized how incomplete an unactionable the majority of GPU hang reports are. Asking users to report bugs, but not telling them what actually constitutes a bug report, is a recipe for a lot of wasted developer time. I suspect we could improve the usefulness of the reports by directing users to a webpage that gave a few suggestions (tell us what you were doing when the hang occurred would be an obvious one) about filing a bug and then provided a link to Bugzilla. Or even configured Bugzilla to have a default template that requested various bits of information. > 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. Indeed. I'd rather have the information provided in a bug report to actually solve it. I hope having access to the shader program will make many more reports useful. I am also happy to see that there's now a sunset to the GPU hang message.