On Thu, May 21, 2015 at 05:37:44PM +0300, Mika Kuoppala wrote: > During review of dynamic page tables series, I was able > to hit a lite restore bug with execlists. I assume that > due to incorrect pd, the batch run out of legit address space > and into the scratch page area. The ACTHD was increasing > due to scratch being all zeroes (MI_NOOPs). And as gen8 > address space is quite large, the hangcheck happily waited > for a long long time, keeping the process effectively stuck. > > According to Chris Wilson any modern gpu will grind to halt > if it encounters commands of all ones. This seemed to do the > trick and hang was declared promptly when the gpu wandered into > the scratch land. > > Signed-off-by: Mika Kuoppala <mika.kuopp...@intel.com> > --- > drivers/gpu/drm/i915/i915_gem_gtt.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c > b/drivers/gpu/drm/i915/i915_gem_gtt.c > index ccdb35f..26d1d45 100644 > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > @@ -2153,6 +2153,7 @@ static int alloc_scratch_page(struct i915_address_space > *vm) > return ret; > } > > + fill_px(vm->dev, sp, ~0ULL);
I'd be tempted to actually use 0xffff00ff. The advantage of 0 is that it is unlikely to be noticeable. The advantage of 0xffff00ff is that is very noticeable. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
