From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ] Date: Tue, 13 Aug 2013 18:13:24 +0100 Message-ID: <20130813171324.GB8805@cantiga.alporthouse.com> References: <20130813095259.GC4519@cantiga.alporthouse.com> <20130813163439.GA8805@cantiga.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Sedat Dilek Cc: Stephen Rothwell , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Daniel Vetter , Dave Airlie , DRI , intel-gfx , "s.dilek" List-Id: linux-next.vger.kernel.org On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote: > On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek = wrote: > > On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson wrote: > >> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote: > >>> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek wrote: > >>> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightl= y: > >>> > > >>> > 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commi= t > >>> > commit 5456fe3882812aba251886e36fe55bfefb8e8829 > >>> > Author: Chris Wilson > >>> > Date: Thu Aug 8 14:41:07 2013 +0100 > >>> > > >>> > drm/i915: Allocate LLC ringbuffers from stolen > >>> > > >>> > As stolen objects now behave identically (wrt to default LL= C cacheing) > >>> > as their normal system counterparts, we no longer have to d= ifferentiate > >>> > our usage for ringbuffers. So allocate them from stolen on = SNB+ as well. > >>> > > >>> > Signed-off-by: Chris Wilson > >>> > Reviewed-by: Ville Syrj=E4l=E4 > >>> > Signed-off-by: Daniel Vetter > >>> > > >>> > :040000 040000 de063a052f39095f4d2f51b49caef9f827df41e8 > >>> > 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers > >>> > > >>> > See also attached files! > >>> > > >>> > >>> With the attached revert-patch my system is OK (with my customize= d X stack). > >> > >> No indication of a GPU hang? I'm puzzled as to how this ends up wi= th the > >> scanout being misread. > >> > >> cat /sys/kernel/debug/dri/0/i915_gem_stolen > >> cat /sys/kernel/debug/dri/0/i915_gem_framebuffer > >> > >> would be interesting. > Attached both outputs with GOOD and BAD (BROKEN) kernel. ggtt offset is the same for both setups, the only difference between th= e two is the location of fbcon in stolen memory. Can you please attach the output of intel_reg_dumper for good/bad? It's a long shot... Speaking of long shots, try this (slightly different to the earlier pat= ch): diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i91= 5/intel_display.c index a21f935..37ad772 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1850,6 +1850,9 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev= , BUG(); } =20 + if (obj->stolen && INTEL_INFO(dev)->gen >=3D 6) + alignment =3D 256 * 1024; + /* Note that the w/a also requires 64 PTE of padding following = the * bo. We currently fill all unused PTE with the shadow page an= d so * we should always have valid PTE following the scanout preven= ting --=20 Chris Wilson, Intel Open Source Technology Centre