public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Stop requesting error_state reports.
Date: Tue, 10 Feb 2015 23:51:56 +0100	[thread overview]
Message-ID: <20150210225156.GS24485@phenom.ffwll.local> (raw)
In-Reply-To: <1423607568.1616.142.camel@rdvivi-hillsboro.jf.intel.com>

On Tue, Feb 10, 2015 at 02:32:48PM -0800, Rodrigo Vivi wrote:
> On Tue, 2015-02-10 at 23:02 +0100, Daniel Vetter wrote:
> > On Tue, Feb 10, 2015 at 11:27:30AM -0800, Rodrigo Vivi wrote:
> > > These error states are great to know gpu state when it hangs.
> > > 
> > > But since we don't have automated tools to do analysis we are
> > > facing much noise on bugzilla with end users reporting just
> > > because "log asked to", while gpu reset worked and users probably
> > > never notice any screen issue. Most of these reportes don't know
> > > when it happened or how to retrigger the issue and somethimes
> > > they are not even on the mood to retest again.
> > 
> > Hm, maybe we should reword it to make sure we only get good testers?
> > 
> > Instead of "Please file ..." do a "If you can build&test kernels and see
> > other issues together with this gpu hang notice file ..."?
> 
> This is just one thing. Some OSVs complains we have to much noise for
> end users. So 2 noises: bugzilla and logs.

OSV noise is a different issue. We have already have
i915.verbose_state_checks for that, maybe we need to add another one for
gpu hangs. But imo that should actually come from OSV, not development
(like Rob Clark has done for the state checker).

> > I agree with Chris that we can't just mute these, overall the information
> > is imo valuable. We just need to get better at filtering them, and have
> > better information in the error states. E.g. with dri3 the pid/commi is
> > always the one for X, Mika has a small patch to fix that.
> 
> I do agree this error state is valuable. I really like it.
> 
> > 
> > Closing our eyes won't make the bugs go away.
> 
> Indeed. But this patch doesn't intend to close the eyes, but just open
> when it has to be opened, i.e. when drm.debug is set.

Imo drm.debug is too silent, we've had that ages ago and it resulted in
lots of unecessary roundtrips in bug reports because reporters almost
never attach the error state if there's a gpu hang. So that imo doesn't
help either with reducing bug team workload. The message is this verbose
because a single line was not good enough ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-02-10 22:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-10 19:27 [PATCH] drm/i915: Stop requesting error_state reports Rodrigo Vivi
2015-02-10 21:14 ` Chris Wilson
2015-02-10 22:02 ` Daniel Vetter
2015-02-10 22:32   ` Rodrigo Vivi
2015-02-10 22:51     ` Daniel Vetter [this message]
2015-02-11  9:14     ` Jani Nikula
2015-02-11  5:45 ` shuang.he

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=20150210225156.GS24485@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rodrigo.vivi@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