On Wed, Feb 22, 2017 at 06:02:46PM +0000, Chris Wilson wrote:
> On Wed, Feb 22, 2017 at 11:39:30AM +0000, Chris Wilson wrote:
> > On Wed, Feb 22, 2017 at 01:27:41PM +0200, Joonas Lahtinen wrote:
> > > On ma, 2017-02-20 at 12:47 +0000, Chris Wilson wrote:
> > > > Testing with concurrent GGTT accesses no longer show the coherency
> > > > problems from yonder, commit 5bab6f60cb4d ("drm/i915: Serialise updates
> > > > to GGTT with access through GGTT on Braswell"). My presumption is that
> > > > the root cause was more likely fixed by commit 3b5724d702ef ("drm/i915:
> > > > Wait for writes through the GTT to land before reading back"), along
> > > > with the use of WC updates to the global gTT in commit 8448661d65f6
> > > > ("drm/i915: Convert clflushed pagetables over to WC maps". Given
> > > > that the original symptoms can no longer be reproduced, time to remove
> > > > the workaround.
> > > >
> > > > Testcase: igt/gem_concurrenct_blit
> > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > > > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx>
> > >
> > > Makes one think if the original fix has been appropriate, when adding
> > > stop_machine for a software bug :P
> >
> > Depends if you consider the months of hair pulling trying to find where
> > the flush/stall was missing. It was a desperate patch to fix an annoying
> > corruption issue - and since it seems that we now just avoid the
> > dangerous path by taking a different route through hw, I don't think
> > it is was wholly a sw bug.
>
> Bah, after a few days of continuous testing, I've hit a workload that
> shows the bug again. (Small numbers of large GTT objects, rather than
> large number of small GTT objects.)
Hmm, and it also died with the w/a with nigh on identical symptoms. And
appears quite tempermental. Uncertainity is prevailing.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
