Re: [PATCH 2/2] drm/i915: Add WaKBLVECSSemaphoreWaitPoll

[Mika Kuoppala <mika.kuoppala@linux.intel.com>]

Chris Wilson <chris@chris-wilson.co.uk> writes:

> Quoting Mika Kuoppala (2018-05-30 16:02:06)
>> There is a problem with kbl up to rev E0 where a heavy
>> memory traffic from adjacent engine(s) can cause an engine
>> reset to fail. This traffic can be from normal memory accesses
>> or it can be from heavy polling on a semaphore wait.
>> 
>> To combat the normal traffic, we do our best to idle the adjacent
>> engines, before we ask the engine to prepare for reset. For per
>> engine reset, this will add an unwanted extra latency as we
>> do blanket approach before every reset. In past already have
>> noticed that idling an engine before reset, improves our chances
>> of resetting it, but this only idles the engines we are about to
>> reset, not the adjancent ones.
>
> Unfortunately we don't have a lock on the other engines, so can't
> prevent two resets running in parallel clobbering state on the other.
>
> So what's stopping the failure mode of falling back to resetting all
> engines at once if resetting one fails? Is it a catastrophic failure?

Nothing that I can think of and for this we should just let the full
reset and it's explicit idling to be our backup plan.

And it if ever shows itself as frequent enough to warrant further
work, we should consider doing a full reset right from the start on
the affected hw.

-Mika
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx