Re: [PATCH 12/18] drm/i915/gtt: Fill scratch page

From: Dave Gordon <david.s.gordon@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Mika Kuoppala <mika.kuoppala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org, miku@iki.fi
Subject: Re: [PATCH 12/18] drm/i915/gtt: Fill scratch page
Date: Fri, 26 Jun 2015 18:31:28 +0100	[thread overview]
Message-ID: <558D8C70.3080501@intel.com> (raw)
In-Reply-To: <20150625175159.GS30757@nuc-i3427.alporthouse.com>

On 25/06/15 18:51, Chris Wilson wrote:
> On Thu, Jun 25, 2015 at 06:35:14PM +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.
>>
>> v2: Use 0xffff00ff pattern (Chris)
> 
> Thinking about this, could we add a scratch page checker to hangcheck?
> Just check the first/last u64 perhaps? Or random offset_in_page?
> -Chris

I've suggested to Tomas that when running in 32-bit PPGTT mode, if ACTHD
is >4G then it's definitely broken. Doesn't help much once PPGTT space
expands to 48b though.

.Dave.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx