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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
