Quoting Tvrtko Ursulin (2019-04-17 08:55:26) > > On 16/04/2019 21:04, Chris Wilson wrote: > > Quoting Chris Wilson (2019-04-16 15:59:38) > >> Quoting Tvrtko Ursulin (2019-04-16 15:53:40) > >>> > >>> On 16/04/2019 15:17, Chris Wilson wrote: > >>>> Quoting Tvrtko Ursulin (2019-04-16 15:10:25) > >>>>> > >>>>> On 16/04/2019 14:14, Chris Wilson wrote: > >>>>>> Read the engine workarounds back using the GPU after loading the initial > >>>>>> context state to verify that we are setting them correctly, and bail if > >>>>>> it fails. > >>>>>> > >>>>>> v2: Break out the verification into its own loop > >>>>>> > >>>>>> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > >>>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > >>>>> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > >>>> > >>>> Now we just have to decide what to do about the +47 icl failures :) > >>>> (Or however many it is this time.) > >>> > >>> I am hardly keeping pace with your patches, let alone looking at the CI > >>> results. :I > >>> > >>> I see BAT success - where to see the failures and what is failing? > >> > >> Wait for the shards. BAT just happens to have machines that work! > >> In the shards we have about a 30% chance (at the last count) of any test > >> that reloads the module to trigger a warning. > > > > With the -EIO if the intel_engines_verify_workaround() failed, we scored > > over 500 changes/failures :) With a whole boatload of tests still trying > > to use the GPU even when wedged. > > With -EIO I guess the only option seems to have the ignore verification > patch back. Even without that, we still get an *ERROR* on every module load and reset. So we still end up with a sea of orange for icl. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
