On 17/04/2019 08:58, Chris Wilson wrote:
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.
Yes, no alternative to having that patch, ignore_write_or or what it was
called.
Retgards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
