On Wed, Aug 14, 2013 at 03:02:37PM +0200, Sedat Dilek wrote: > On Wed, Aug 14, 2013 at 3:01 PM, Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote: > > On Wed, Aug 14, 2013 at 2:52 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > >> On Wed, Aug 14, 2013 at 02:31:24PM +0200, Sedat Dilek wrote: > >>> Requested output and dmesg files attached. > >>> ( Should I attach the one with "BROKEN" display - I mean w/o doing a > >>> re-login and display "REPAIRED"? ) > >> > >> Yes please. > > > > Attached tarball contains: > > > > 130413 Aug 14 14:52 > > dmesg_3.11.0-rc5-next20130814-1-iniza-small_drm-debug-6_0-before-relogin-lightdm-unity2d_VT-1.txt > > 145973 Aug 14 14:53 > > dmesg_3.11.0-rc5-next20130814-1-iniza-small_drm-debug-6_1-before-relogin-lightdm-unity2d_X.txt > > 199199 Aug 14 14:55 > > dmesg_3.11.0-rc5-next20130814-1-iniza-small_drm-debug-6_2_after-relogin-lightdm-unity2d_X.txt > > > > 79398 Aug 14 14:53 > > i915_gem_gtt_drm-debug-6_1-before-relogin-lightdm-unity2d_X.txt > > 108374 Aug 14 14:55 > > i915_gem_gtt_drm-debug-6_2_after-relogin-lightdm-unity2d_X.txt The PTE values do correspond with the stolen addresses for the framebuffer. So I am resonably confident that the driver is self-consistent at least. DSPSURF points to the right location in the GGTT and those entries point to the right location in stolen. The display on the other hand seems to be continuing to read from GGTT offset 0, and so the real framebuffer appears offset by a few lines. How about trying https://patchwork.kernel.org/patch/2841934/ ? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
