All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Intel GFX <intel-gfx@lists.freedesktop.org>,
	Ben Widawsky <ben@bwidawsk.net>,
	Ben Widawsky <benjamin.widawsky@intel.com>
Subject: Re: [PATCH] [RFC] drm/i915: Generate a hang error code
Date: Wed, 5 Feb 2014 16:03:45 +0000	[thread overview]
Message-ID: <20140205160345.7cc020ca@jbarnes-t420> (raw)
In-Reply-To: <20140205151502.GG17001@phenom.ffwll.local>

On Wed, 5 Feb 2014 16:15:02 +0100
Daniel Vetter <daniel@ffwll.ch> wrote:

> On Wed, Feb 05, 2014 at 02:59:08PM +0000, Jesse Barnes wrote:
> > On Tue,  4 Feb 2014 12:18:55 +0000
> > Ben Widawsky <benjamin.widawsky@intel.com> wrote:
> > 
> > > We get a large number of bugs which have a, "hey I have that too"
> > > because they see a GPU hang in dmesg. While two machines of the same
> > > model having a GPU hang is indeed a coincidence, it is far from enough
> > > evidence to suggest they are the same.
> > > 
> > > In order to reduce this effect, and hopefully get people to file new bug
> > > reports, clearly the error message itself has been insufficient (see ref
> > > at the bottom for a new bug report with this characteristic).
> > > 
> > > The algorithm is purposely pretty naive. I don't think we need much in
> > > order to avoid the problem I am trying to solve, and keeping it naive
> > > gives us some ability to make a decent test case.
> > 
> > I like the direction of this.  If we can get some basic info into the
> > dmesg part of things (the only part regular users will actually look
> > at) we can probably avoid some of the "me too" action we see on general
> > GPU hangs.  Having PID, comm, and some sort of hang signature are all
> > good steps in that direction imo.
> 
> tbh I don't see much value in regular users trying to triage gpu hang. If
> they're not damn sure that they have a dupe (which means same platform,
> versions of the software stack and crashing games) I much prefer if they
> just send in a duplicate bug for us to triage.
> 
> With the mis-design of bugzilla it's much harder to untangle a wrong
> me-too than mark something as duplicate. And especially long-running bugs
> are a royal pain if there's too much wrong me-too noise in there.
> 
> Not a comment on the patch itself, just a general comment wrt avoiding
> me-too gpu hang reports.

So you're saying the GPU error decode tool should create a bug template
for people so we don't get the "me too" reports?

What I see above is that it's really important to avoid the "me too"
stuff, and to do it in such a way that false positives are minimized
(e.g. the IPEHR bit Ubuntu used to use).  So I guess I don't see what's
unconvincing here.  Today we have no way of differentiating w/o digging
in to the error record, which users definitely won't do, and this patch
seems like it could only help with that... so count me confused.

Jesse

  reply	other threads:[~2014-02-05 16:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-04 12:18 [PATCH] [RFC] drm/i915: Generate a hang error code Ben Widawsky
2014-02-04 12:43 ` Daniel Vetter
2014-02-05 14:59 ` Jesse Barnes
2014-02-05 15:15   ` Daniel Vetter
2014-02-05 16:03     ` Jesse Barnes [this message]
2014-02-05 16:18       ` Daniel Vetter
2014-02-05 16:30         ` 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=20140205160345.7cc020ca@jbarnes-t420 \
    --to=jbarnes@virtuousgeek.org \
    --cc=ben@bwidawsk.net \
    --cc=benjamin.widawsky@intel.com \
    --cc=daniel@ffwll.ch \
    --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.