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]

Date:   Mon, 5 Dec 2016 16:55:47 -0800
From:   Matt Turner <mattst88@...il.com>
To:     Jani Nikula <jani.nikula@...ux.intel.com>
Cc:     "intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
        Daniel Vetter <daniel.vetter@...el.com>,
        Mika Kuoppala <mika.kuoppala@...el.com>,
        Kenneth Graunke <kenneth@...tecape.org>,
        Mark Janes <mark.a.janes@...el.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "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, Dec 3, 2016 at 1:52 AM, Jani Nikula <jani.nikula@...ux.intel.com> wrote:
> 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?

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.