[Intel-gfx] [PATCH 2/2] drm/i915: Verify the engine workarounds stick on application

[Tvrtko Ursulin]

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 at chris-wilson.co.uk>
>>>>>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>>>>>> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>>>>>
>>>>>> 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