On Wed, Aug 14, 2013 at 3:44 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > 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/ ? The same screen corruption (see also attached tarball). - Sedat -
Attachment:
for-ickle-3.tar.xz
Description: Binary data
Attachment:
for-ickle-3.tar.xz.sha256sum
Description: Binary data
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
