[Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]

Chris Wilson chris at chris-wilson.co.uk
Tue Aug 13 19:13:24 CEST 2013


On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek <sedat.dilek at gmail.com> wrote:
> > On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson <chris at chris-wilson.co.uk> 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 <sedat.dilek at gmail.com> wrote:
> >>> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:
> >>> >
> >>> > 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
> >>> > commit 5456fe3882812aba251886e36fe55bfefb8e8829
> >>> > Author: Chris Wilson <chris at chris-wilson.co.uk>
> >>> > 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 LLC cacheing)
> >>> >     as their normal system counterparts, we no longer have to differentiate
> >>> >     our usage for ringbuffers. So allocate them from stolen on SNB+ as well.
> >>> >
> >>> >     Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >>> >     Reviewed-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >>> >     Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> >>> >
> >>> > :040000 040000 de063a052f39095f4d2f51b49caef9f827df41e8
> >>> > 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M      drivers
> >>> >
> >>> > See also attached files!
> >>> >
> >>>
> >>> With the attached revert-patch my system is OK (with my customized X stack).
> >>
> >> No indication of a GPU hang? I'm puzzled as to how this ends up with 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 the
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 patch):

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/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();
        }
 
+       if (obj->stolen && INTEL_INFO(dev)->gen >= 6)
+               alignment = 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 and so
         * we should always have valid PTE following the scanout preventing


-- 
Chris Wilson, Intel Open Source Technology Centre



More information about the Intel-gfx mailing list