Originally the thought for the assertion was that if there are no real VMAs (died during execbuf), or there is only 1 VMA, but the VMA is on the active list, it's a bug. The former case is pretty obvious. The later case simply meant to assert the context unref/object retire interactions were working properly There is a flaw in the logic of the second when an object has multiple VMAs. If there are multiple VMAs, it's possible that the object continually had it's seqno increased as it was used by another context. In this case, the context ref will die, but the VMA will not be taking off the active list because of the missing retire seqno for a VMA. Like some of the other fixes I've submitted recently, this should be fixed by the eventual work Daniel will do. This is pretty easy to reproduce whenever mesa uses the blit engine. Signed-off-by: Ben Widawsky <ben@xxxxxxxxxxxx> --- drivers/gpu/drm/i915/i915_gem_context.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index ef256ae..a5c7d5d 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -145,8 +145,7 @@ static int do_ppgtt_cleanup(struct i915_hw_ppgtt *ppgtt) do_idle = true; list_for_each_entry(vma, &vm->active_list, mm_list) - if (WARN_ON(list_empty(&vma->vma_link) || - list_is_singular(&vma->vma_link))) + if (WARN_ON(list_empty(&vma->vma_link))) break; } else i915_gem_retire_requests(dev); -- 2.0.4 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
