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@xxxxxxxxx> wrote: > > On Thu, Aug 22, 2013 at 1:32 PM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > >> On Thu, Aug 22, 2013 at 1:30 PM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > >>> On Thu, Aug 22, 2013 at 1:13 PM, Sedat Dilek <sedat.dilek@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> > >> 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 -- 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
