On 06/10/2015 03:59 AM, Imre Deak wrote: > I think the discussion here is about two separate things: > 1. Possible ordering issue between the seqno store and the completion > interrupt > 2. Coherency issue that leaves the CPU with a stale view of the seqno > indefinitely, which this patch works around > > I'm confident that in my case the problem is not due to ordering. If it > was "only" ordering then the value would show up eventually. This is not > the case though, __wait_for_request will see the stale value > indefinitely even though it gets woken up periodically afterwards by the > lost IRQ logic (with hangcheck disabled). Yeah, based on your workaround it sounds like the write from the CS is landing in memory but failing to invalidate the associated CPU cacheline. I assume mapping the HWSP as uncached also works around this issue? I wonder if this is just an issue with GGTT mappings on BXT. If we had per context HSWPs using PPGTT (and maybe even 48 bit PPGTT) mappings, the snoop may be performed correctly... Looks like we don't have a store_dword variant for explicit coherent or incoherent buffer writes (though it does test PPGTT writes at least); that would make this easy to test. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
