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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx>
> > 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@xxxxxxxxxxxxxxxxxx>
> >     Reviewed-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> >     Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
> >
> > :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
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux