On 03/01/2017 11:05, Chris Wilson wrote:
The struct dma_fence carries a status field exposed to userspace by sync_file. This is inspected after the fence is signaled and can convey whether or not the request completed successfully, or in our case if we detected a hang during the request (signaled via -EIO in SYNC_IOC_FILE_INFO).Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com> Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com> --- drivers/gpu/drm/i915/i915_gem.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 204c4a673bf3..bc99c0e292d8 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2757,10 +2757,12 @@ static void i915_gem_reset_engine(struct intel_engine_cs *engine) ring_hung = false; } - if (ring_hung) + if (ring_hung) { i915_gem_context_mark_guilty(request->ctx); - else + request->fence.status = -EIO; + } else { i915_gem_context_mark_innocent(request->ctx); + } if (!ring_hung) return;
Reading what happens later in this function, should we set the status of all the other requests we are about to clear?
However one thing I don't understand is how this scheme interacts with the current userspace. We will clear/no-nop some of the submitted requests since the state is corrupt. But how will userspace notice this before it submits more requets?
Regards, Tvrtko _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
