On Mon, Apr 20, 2020 at 11:21:42AM +0300, Joonas Lahtinen wrote:
So it seems that the patch got pulled into v5.6 and has been backported to v5.5 but not v5.4.
You're right, that's my mistake.
In doing that zeroing of ring->vaddr is removed so the test to do mdelay(1) and "ring->vaddr = NULL;" is not correct.
I'm not so sure about this. Look at where `ring->vaddr` is assigned: -------------------------------------8<----------------------------------------- ret = i915_vma_pin(vma, 0, 0, flags); if (unlikely(ret)) goto err_unpin;
if (i915_vma_is_map_and_fenceable(vma)) addr = (void __force *)i915_vma_pin_iomap(vma); else addr = i915_gem_object_pin_map(vma->obj, i915_coherent_map_type(vma->vm->i915)); if (IS_ERR(addr)) { ret = PTR_ERR(addr); goto err_ring; }
i915_vma_make_unshrinkable(vma);
/* Discard any unused bytes beyond that submitted to hw. */ intel_ring_reset(ring, ring->emit);
ring->vaddr = addr; ------------------------------------->8-----------------------------------------
And then the converse of that is done *before* my reproducer patch does `ring->vaddr = NULL;`: -------------------------------------8<----------------------------------------- i915_vma_unset_ggtt_write(vma); if (i915_vma_is_map_and_fenceable(vma)) i915_vma_unpin_iomap(vma); else i915_gem_object_unpin_map(vma->obj);
/* mdelay(1); ring->vaddr = NULL; */
i915_vma_make_purgeable(vma); i915_vma_unpin(vma); ------------------------------------->8-----------------------------------------
Isn't the value assigned to `ring->vaddr` trashed by those function calls above where I've got the mdelay? If so, why would it be correct to let the stale value sit in `ring->vaddr`?
My interpretation of the zeroing of ring->vaddr being removed by Chris was that it was an unnecessary step before the ring was getting discarded anyway.
Sultan