From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 2/2] drm/i915: drop the guard page at the end of the gtt Date: Tue, 31 Jan 2012 20:08:47 +0100 Message-ID: <20120131190847.GH3911@phenom.ffwll.local> References: <1327938949-5921-1-git-send-email-daniel.vetter@ffwll.ch> <1327938949-5921-2-git-send-email-daniel.vetter@ffwll.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by gabe.freedesktop.org (Postfix) with ESMTP id D72219E7EF for ; Tue, 31 Jan 2012 11:08:45 -0800 (PST) Received: by wico1 with SMTP id o1so320348wic.36 for ; Tue, 31 Jan 2012 11:08:45 -0800 (PST) Content-Disposition: inline In-Reply-To: <1327938949-5921-2-git-send-email-daniel.vetter@ffwll.ch> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Intel Graphics Development Cc: Daniel Vetter List-Id: intel-gfx@lists.freedesktop.org On Mon, Jan 30, 2012 at 04:55:49PM +0100, Daniel Vetter wrote: > 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 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44748 > Signed-Off-by: Daniel Vetter Ok, I've seriously botched things up at testing. This actually blows up my g33 (which works fine without the patch), so we need that darn guard page. I'll fix this mess up. -Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48