[Intel-gfx] [PATCH 16/20] drm/i915/gtt: Fill scratch page

[Chris Wilson]

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.kuoppala at 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