Rows of pixels screen corruption

[hey560]

Binary package hint: xserver-xorg-video-intel

I see 2 rows of pixel corruption every time I Suspend to RAM/Resume, and also, intermittently, from a cold boot.

A row of pixels on the right side of the screen are swapped with another row of pixels on the left side of the screen. See screenshot: http://img20.imageshack.us/img20/8972/corruptionvn1.png

- Only occurs at my highest resolution, 1680x1050 (does not occur at 1280x800 or less).
- Only occurs when I have DRI enabled in my xorg.conf and loaded
- This bug was reported on Xorg bugzilla a few months ago. It went away with the 1.9.9x branch of the driver, and now has resurfaced with the 2.0.x branch in Gutsy.
    - Xorg Bugzilla #9381: http://bugs.freedesktop.org/show_bug.cgi?id=9381

Relevant Information:
- Kernel: Linux corvallis 2.6.22-13-generic #1 SMP Thu Oct 4 17:18:44 GMT 2007 i686 GNU/Linux

- Relevant lspci:
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA])
        Subsystem: Lenovo Unknown device 2062
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at d0200000 (32-bit, non-prefetchable) [size=512K]
        Region 1: I/O ports at 1800 [size=8]
        Region 2: Memory at c0000000 (32-bit, prefetchable) [size=256M]
        Region 3: Memory at d0300000 (32-bit, non-prefetchable) [size=256K]
        Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
                Address: 00000000 Data: 0000
        Capabilities: [d0] Power Management version 2

- dmesg |grep drm:
[ 30.344000] [drm] Initialized drm 1.1.0 20060810
[ 30.348000] [drm] Initialized i915 1.6.0 20060119 on minor 0

[Javier Ruiz (jrhbcn)]

I see the same on my external monitor (not on the laptop panel though) at 1280x1024. lspci reports my card as "Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)".

Hope it helps.

[Peter Clifton (pcjc2)]

Can you post your log file from /var/log/Xorg.0.log and the config file /etc/X11/xorg.conf please?

[hey560 (hey560)]

I have attached the Xorg.0.log before suspend/resume (and thus before corruption) and also after suspend/resume. Along with my xorg.conf

[Jamie Lokier (jamie-shareable)]

See bug #134464 which is probably the same.

I see similar corruption consistently when using an external monitor 1680x1050. There is no need for suspend/resume. Merely dragging a window round will produce it. With my laptop screen I never see it, at 1280x1024.

It is easily reproduced in my setup: it's there from the start, or it's not (with the right older driver).

The artifact looks suspiciously like problems in a 2d acceleration op such as block copy/fill. It is not a problem displaying the framebuffer contents, because it can be drawn over with the correct pixels, so it's definitely a drawing problem of some kind. It's not 3d related: I'm not using any 3d acceleration - no Compiz, etc.

This bug was fixed in an older version of the Intel X.Org driver, and got fixed around 2.0.0. The Feisty version of the Intel driver on burtonini.com worked well. But the bug seems to have reappeared in Gutsy's version for quite some time. Unfortunately I forget when exactly it reappeared, as I assumed it would be so obvious that it would get fixed quickly, but it hasn't been fixed for several Intel driver updates in Gutsy.

Because it was fixed for a while, I suspect this is a known fixed bug in X.Org's version which got lost during some code merging accident.

[Peter Clifton (pcjc2)]

I went over the commit logs from 1.9.? to 2.0.0 before, looking for how this had been fixed originall, and could not see anything which referenced the bug, or immediately jumped out as being a likely suspect.

If you're interested to help debug this, you could grab the git version of the drvier from git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel
(git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel)

You should be able to use the "git bisect" tool between a known good, and a known bad point to identify where the problem started.

Just be careful to keep track of which files you end up over-writing with a non-debian packaged version of the driver.. or if you are so inclined, you could actually use much of the "debian" directory from the real driver to built a .deb for each step in the biesction.

[Jamie Lokier (jamie-shareable)]

As I've reported in bug #134464, a package from October 4th git head by Bryce Harrington, _does_ seem to fix the row of pixels problem at least for me.

That package (which fixes the row of pixels) is http://people.ubuntu.com/~bryce/Testing/intel/xserver-xorg-video-intel_2.1.1~git20071004-0ubuntu1_i386.deb

The package mentioned in bug #114331 by Peter Cliften does _not_ fix the row of pixels problem. I tried it, and it worked fine (no new problems that I saw during the brief test), but the corrupt row of pixels was still obvious.

That package (which doesn't fix the row of pixels) is
http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/xserver-xorg-video-intel_2.1.1-0ubuntu10~pcjc2.2_i386.deb

Thanks muchly. I shall continue using Bryce's package for now.