Bug 55551

Created attachment 68004 [details]
Image on website

Please do attach your Xorg.log.

Created attachment 68005 [details]
Current Xorg.0.log

On the log are some "VT switch"es. I did them just to check if the graphical glitches would fade away. They didn't.

First you'll want to try kernel 3.4 (at least) for

commit c9c4b6f6c28354f1df9bd288dc33ba7ae0e66aaa
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Dec 14 13:57:15 2011 +0100

    drm/i915: fix swizzle detection for gen3
    
    It looks like the desktop variants of i915 and i945 also have the DCC
    register to control dram channel interleave and cpu side bit6
    swizzling.
    
    Unfortunately internal Cspec/ConfigDB documentation for these ancient chips
    have already been dropped and there seem to be no archives. Also
    somebody thought the swizzling behaviour is surely a worthy secret to
    keep and redacted any mention of these fields from the published Intel
    datasheets.
    
    I suspect the hw engineers were really proud of the page coloring
    they've achieved in their first dual channel dram controller with
    bit17 - after all Bspec explains in great length the optimal layout of
    page frame numbers modulo 4 for the color and depth buffers, too.
    Later on when they've started to work on VT-d they shamefully
    discoverd their stupidity and tried to cover the tracks ...

    Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch> (i915g)
    Tested-by: Pavel Ondračka <pavel.ondracka@email.cz> (i945g)
    Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42625
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

and

commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Mar 21 10:48:18 2012 +0000

    drm/i915: Mark untiled BLT commands as fenced on gen2/3
    
    The BLT commands on gen2/3 utilize the fence registers and so we cannot
    modify any fences for the object whilst those commands are in flight.
    Currently we marked tiled commands as occupying a fence, but forgot to
    restrict the untiled commands from preventing a fence being assigned
    before they were completed.
    
    One side-effect is that we ten have to double check that a fence was
    allocated for a fenced buffer during move-to-active.

Hi Chris.

I tested with kernel 3.5.2, which is currently available at the experimental Debian repos. This issue appears to be fixed there! Thank you a lot for your quick reply.

Given that the upcoming "stable" Debian version is due to be shipped with a 3.2 kernel, I'm now testing those patches as well as [1] against this version (3.2.23). The surrounding, patched code seemed similar to the code on 3.5. Do you think there might be any problem in including these on this version for any particular reason? Is there a strong dependency on any 3.4 feature?
If not, I'm going to suggest to the Debian maintainers to include them on this kernel.

Thanks again and best regards,
Luís Picciochi


1 - 
commit 15a13bbdffb0d6288a5dd04aee9736267da1335f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>	
Date:   Thu 12 Apr 2012 07:02:37 +0000

    drm/i915: clear fencing tracking state when retiring requests

    This fixes a resume regression introduced in

    commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Wed Mar 21 10:48:18 2012 +0000

        drm/i915: Mark untiled BLT commands as fenced on gen2/3

    which fixed fencing tracking for untiled blt commands.
    (...)

Indeed, those patches are standalone (modulo the fixup as you spotted) and should be backported to 3.2 as stability fixes.

*** This bug has been marked as a duplicate of bug 42625 ***