[Intel-gfx] [PATCH] drm/i915/selftests: Log test and subtest names for easier debugging
Chris Wilson
chris at chris-wilson.co.uk
Tue Nov 20 18:24:03 UTC 2018
Quoting Tvrtko Ursulin (2018-11-20 18:18:00)
>
> On 20/11/2018 18:10, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-11-20 17:58:33)
> >>
> >> On 20/11/2018 17:33, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-11-20 17:28:39)
> >>>> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> >>>>
> >>>> Since pr_debug is not printed by default, change both test and subtest
> >>>> log messages to pr_info so they are always logged.
> >>>
> >>> I just use the trace... As when the test fails we say which subtest
> >>> failed, and hopefully include more details in the error message, and
> >>> recent history is in the trace dumped when considered relevant.
> >>
> >> Fair. My thinking was simply to leave more breadcrumbs if the machine
> >> died in the middle of a subtest.
> >
> > Thinking more about it, the easiest option would be to actually enable
> > pr_debug, iirc a config option.
>
> AFAICT we would need to pass -DDEBUG to interesting compilation units.
>
> > However, the only time we don't get breadcrumbs is if the machine
> > spontaneously combusts, which we are told is a mere figment of our
> > imagination. Most often I wonder if we simply do not get the death
> > throes - adding logging won't help if we don't capture it. For the true
> > spontaneous combustion, it's pretty random and all I can think of
> > suggesting are more sanity checks to try and catch inconsistencies early.
>
> Well I was looking at one such log today so hence the patch.. :)
But given the number of unexplained skl lockups, looking at a sporadic
(if not one off) example as opposed to say gem_cpu_reloc which kills
shard-skl every time seems like hunting in the dark.
-Chris
More information about the Intel-gfx
mailing list