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@xxxxxxxxx> > >>>> > >>>> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
