Chris Wilson reported that with a bunch of patches to no longer force batchbuffer (in most cases at least) into the mappable part of gtt that his Pineview died while prefetching the last page of the gtt. Turns out that since my intel-gtt rewrite we don't actually put a dummy pte in that last page anymore. Which left me rather puzzled because Chris' error_state was the first ever since that rewrite that indicated a dead gpu due to prefetch. So I've gone ahead and created the gem_cs_prefetch testcase which reliably manages to execute a batch on the last page. Of all the machines Chris and I have tried this on only his Pineview fell over, all the others handled the invalid pte right after the end of the batch correctly. The other thing is that due to my intel-gtt we've also started to use the non-mappable part of the gtt. So my theory is that this guard page was only necessary when we didn't use and hence also didn't set up any dummy ptes to the scratch page in that area. In that case the cs would prefetch into the unmappable gtt area and fail over on the invalid pte. So given that this guard page smells like it just duct-taped over an issue in our code I've simply removed it. And this seems to work! Now we always run the risk that an odd machine we don't have in our test labs needs this, but - we now have an excellent testcase to diagnose any such issues - and the patch is easy to revert. Hence I prefer if we try to get rid of this. Tested-by: Chris Wilson <chris at chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44748 Signed-Off-by: Daniel Vetter <daniel.vetter at ffwll.ch> --- drivers/gpu/drm/i915/i915_dma.c | 11 +---------- 1 files changed, 1 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 51bbd03..6f918be 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1197,16 +1197,7 @@ static int i915_load_gem_init(struct drm_device *dev) drm_mm_init(&dev_priv->mm.stolen, 0, prealloc_size); mutex_lock(&dev->struct_mutex); - /* Let GEM Manage all of the aperture. - * - * However, leave one page at the end still bound to the scratch page. - * There are a number of places where the hardware apparently - * prefetches past the end of the object, and we've seen multiple - * hangs with the GPU head pointer stuck in a batchbuffer bound - * at the last page of the aperture. One page should be enough to - * keep any prefetching inside of the aperture. - */ - i915_gem_do_init(dev, 0, mappable_size, gtt_size - PAGE_SIZE); + i915_gem_do_init(dev, 0, mappable_size, gtt_size); ret = i915_gem_init_ringbuffer(dev); mutex_unlock(&dev->struct_mutex); -- 1.7.8.3
