[RFC] drm/i915: tame the chattermouth

[Jani Nikula]

On Fri, 12 Dec 2014, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Fri, Dec 12, 2014 at 08:17:23AM +0100, Daniel Vetter wrote:
>> On Thu, Dec 11, 2014 at 06:18:12PM -0500, Rob Clark wrote:
>> > Many distro's have mechanism in place to collect and automatically file
>> > bugs for failed WARN()s.  And since every third line in i915 is a WARN()

Come on Rob, that's not necessary.

>> > it generates quite a lot of noise which is somewhat disconcerting to the
>> > end user.
>> > 
>> > Separate out the internal hw-is-in-the-state-I-expected checks into
>> > I915_WARN()s and allow configuration via i915.verbose_checks module
>> > param about whether this will generate a full blown stacktrace or just
>> > DRM_ERROR().
>> > 
>> > Signed-off-by: Rob Clark <robdclark at gmail.com>
>> 
>> Yeah I guess makes sense, although I still claim that these are as much
>> "we've lost track of shit" bugs as when a refcount underflows or a pointer
>> is NULL when it shouldn't. But I also agree that we've done a stellar job
>> this year at not locking at these bugs, so meh.
>
> How about making the state checker WARNs conditional on drm.debug&2? The
> premise is that they are often tantalising unhelpful without the debug
> log, so only show them when we have both?

As I suggested in an internal mail just days ago, make the checks emit a
DRM_ERROR normally (but do log something!), and a WARN if drm.debug &
DRM_UT_KMS (or DRM_UT_DRIVER like Chris suggests) holds.

I object to adding new kernel parameters for this. We have enough, and
our bug fixing efforts really don't need another round of "oh please
*also* enable this new parameter we added".

BR,
Jani.


> -Chris
>
> -- 
> Chris Wilson, Intel Open Source Technology Centre
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center