Bug 55551 - [i915] Images garbled after a while (tiling artifact)
Summary: [i915] Images garbled after a while (tiling artifact)
Status: RESOLVED DUPLICATE of bug 42625
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Chris Wilson
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-02 17:18 UTC by Pitxyoki
Modified: 2012-10-03 14:30 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Corruption on desktop background. (2.34 MB, image/png)
2012-10-02 17:18 UTC, Pitxyoki
no flags Details
Image on website (1.19 MB, image/png)
2012-10-02 17:19 UTC, Pitxyoki
no flags Details
Current Xorg.0.log (55.07 KB, text/plain)
2012-10-02 17:26 UTC, Pitxyoki
no flags Details

Description Pitxyoki 2012-10-02 17:18:09 UTC
Created attachment 68003 [details]
Corruption on desktop background.

Hi,

This (or something very similar) has already been reported on the Ubuntu Launchpad [see footnotes 1,2]. I tried to find a similar report here but I couldn't, so I'm not sure if you're aware of this old issue.

After some time using my computer I notice that some images start getting "damaged". The usual symptom is that some squares or rectangles appear in the wrong location of the image. The situation tends to aggravate if I use the computer for several hours: icons and menu textes eventually start getting "garbled" and the graphical system becomes unusable if I don't restart X or the computer.

I often see my desktop's background image with this effect after some browsing sessions (see attachment). This also happens while browsing, on the images rendered by browsers (both on Iceweasel and Chromium). For example, sites with big and/or many images often display this (see also attached screenshot from [3]).

This appears to be frequent when some program consumes all available physical RAM and the system starts swapping or when some program requests frequent I/O (such as r/w disk operations).

Using destkop environments with fancy effects (Gnome Shell) increases the frequence of these glitches and they're not usable at all because of that.


I'm on Debian testing, i386.

Package versions:
libdrm-intel1: 2.4.33-3
xserver-xorg-video-intel: 2:2.19.0-5


GPU details (lspci -vvv):
00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (rev 04) (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. P5GD1-VW Mainboard
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at cfc80000 (32-bit, non-prefetchable) [size=512K]
        Region 1: I/O ports at a800 [size=8]
        Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M]
        Region 3: Memory at cfd80000 (32-bit, non-prefetchable) [size=256K]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: i915


Please ask if you need more information.

Best regards,
Luís Picciochi

1 - https://bugs.launchpad.net/ubuntu/+source/unity/+bug/985539
2 - https://bugs.launchpad.net/ubuntu/+source/unity/+bug/975306
3 - http://www.boston.com/bigpicture/2010/04/more_from_eyjafjallajokull.html
Comment 1 Pitxyoki 2012-10-02 17:19:13 UTC
Created attachment 68004 [details]
Image on website
Comment 2 Chris Wilson 2012-10-02 17:21:50 UTC
Please do attach your Xorg.log.
Comment 3 Pitxyoki 2012-10-02 17:26:01 UTC
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.
Comment 4 Chris Wilson 2012-10-02 17:30:17 UTC
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.
Comment 5 Pitxyoki 2012-10-03 14:23:30 UTC
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.
    (...)
Comment 6 Chris Wilson 2012-10-03 14:30:47 UTC
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 ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.