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

[Chris Wilson]

On Fri, Aug 23, 2013 at 10:04:37AM +0200, Sedat Dilek wrote:
> On Fri, Aug 23, 2013 at 9:55 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote:
> > On Thu, Aug 22, 2013 at 1:32 PM, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> >> On Thu, Aug 22, 2013 at 1:30 PM, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> >>> On Thu, Aug 22, 2013 at 1:13 PM, Sedat Dilek <sedat.dilek at gmail.com> wrote:
> >>>> dmesg (a lot of traces) and kernel-config attached.
> >>>>
> >>>> UXA causes still screen corruption.
> >>>
> >>> Hm, was only a slim chance that this patch would fix anything - I
> >>> think you'd always see an oops when you'd hit this bug instead of just
> >>> a bit of corruption.
> >>
> >> Ok, I think it's time to throw in the towel a bit. I've dropped
> >>
> >>
> >> commit d46f1c3f1372e3a72fab97c60480aa4a1084387f
> >> Author: Chris Wilson <chris at chris-wilson.co.uk>
> >> Date:   Thu Aug 8 14:41:06 2013 +0100
> >>
> >>     drm/i915: Allow the GPU to cache stolen memory

Hmm, wrong patch. Unless you have a good reason, you just want to drop
the ringbuffers in stolen.

> >> from my queue. I guess we can retry for 3.13 again.
> >
> > I am sorry to keep someone's work to be delayed, really.
> > I would have liked to see this fixed (and I have spent some time on it).

It's just a minor memory optimization (reclaiming less than a megabyte
of system memory).

> > Which patches did you exactly drop?
> >
> 
> Sorry for bombing you with question...
> 
> I am trying latest Linus-tree HEAD with the drm-intel-nightly I made
> my last testings.
> 
> Are any of these TLB / x86-get_unmapped_area fixes of interested...
> has any effects on the reported issue?

It should not. Of concern is how the GPU views the world which has its
own independent set of TLBs and mapping tables - and access to those
should always be uncached from the CPU's perspective.
 
> I still wonder what is the root-cause...
> I mean if SNA is OK but UXA not and Linux graphics stack is that complex.
> ( Can't say if user-space like unity isn't involved... ).

All that userspace can affect here is the timing and inital contents of
the framebuffer, everything else is controlled by the kernel. All the
testing we have done so far imply that the kernel's view of the machine
state is consistent with our expectations, but the display is doing
something inexplicable.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre