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

[Chris Wilson]

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.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre