On Fri, 12 Dec 2014, Chris Wilson chris@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@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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel