On Fri, Oct 23, 2015 at 06:43:32PM +0100, Chris Wilson wrote: > (I have not looked for any pattern such > as modifying PTE within the same page or cacheline as active PTE - > though checking whether revoking neighbouring objects should be enough > to test that theory.) So, fwiw, I revoked the CPU PTE for the neighbouring objects (each object is 1MiB in size and so should occupy 2KiB in the GGTT) but the corruption persisted. If I didn't make a mistake that should squash the theory that it is access through PTE neighbouring the update that are trampled upon. I had also earlier ioremaped the GGTT (dev_priv->gtt.gsm) as uncached, and thrown countless mb() around to rule out incomplete writes to the GGTT prior to CPU access. I haven't tried idling the GPU, as other tests within gem_concurrent_blit demonstrate that is not a GPU flushing issue. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
