Quoting Chris Wilson (2018-03-27 22:01:56) > Now that we reload both RING_HEAD and RING_TAIL when rebinding the > context, we do not need to scrub those registers immediately on resume. So CI reports that contrary to my belief, we didn't do a i915_gem_contexts_lost() across suspend. Hmm, nope that's definitely there in i915_gem_suspend, so all contexts should have been unpinned. Oh, silly me, that doesn't account for the extra perma-pin we keep on the kernel contexts to avoid them being evicted. Ok, that's annoying and has some ramifications for the first patch if we can contrive a wedging to be injected into the kernel context. Hmm, an outside possibility to be sure as it would need a full device reset at precisely the same time as a i915_gem_switch_to_kernel_context, exceedingly rare. Not so rare as having the kernel context be an innocent victim (the last context on an idle engine) - that's not impacted by this, as there we know the breadcrumb has already been emitted so RING_HEAD will not roll back and reemit on recovery. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
