Display corruption in VTs on Intel 855GME

[jhansonxi]

Binary package hint: xserver-xorg-video-intel

Toshiba M35X-S114 with an Intel 855GME chipset.
When I switch to a virtual terminal I often get a persistent large vertical white line in various places covering text. Once present, it's is visible on all VTs and not affected by screen output. If I switch to an X session and back again it either disappears or shows up somewhere else. It does not occur with the vesa driver (or at least very rarely).

[jhansonxi (jhansonxi)]

Attached log with Option ForceEnablePipeA "true" to work around bug #204603

[Frode M. Døving (frode)]

I have this issue too. Current hardy on a Dell Latitude D620 with an intel 945GM.

I upgraded to the xserver-xorg-video-intel 2:2.2.99.902-1 from debian experimental.
That works flawlessly so far. No more graphical artifacts nor lockups for me.

[Khashayar Naderehvandi (khashayar)]

I have this issue too, although it seems to be harmless.

@Frode: Did you just install the .deb straight out of Debian's experimental?

[Frode M. Døving (frode)]

Khashayar: No, I didn't try that. I got the source and buildt it on hardy.

It did have a build-time dependency on a newer libpciaccess (if i recall correctly).
Those packages installed directly from experimental without recompile.

More info on the issue:
I still can not logout from KDE4 and get kdm back without it locking up.
But I can switch from a logged in session to a VT without it locking up, which is improvement from the default hardy totally broken, could not logout, switch VT, or anything.

I believe this is related to some compositing stuff. I can still use KDE3, and logout/in/switch VT without freeze.
But as soon as i start compiz or KDE4 with desctop effects, something goes wrong on logout.

[Bryce Harrington (bryce)]

I have built a fairly recent git snapshots of -intel that you can grab here for testing:

http://people.ubuntu.com/~bryce/bisect/

If it does resolve the issue, it would be helpful if you could check some of the versions between Hardy/2.2.1-1ubuntu5 and 2.2.99.901 on that page, as this will help narrow down which patch may have solved it. We can then pull that patch in for Hardy.

Also, in your description you said it didn't occur with vesa "(or at least very rarely)". If testing the latest git deb of the -intel driver doesn't make the issue go away, could you test on -vesa more and see if you can definitively determine whether the issue occurs with -vesa too? If it does, then it may not be a driver issue after all, and may instead be a hardware, kernel, or xserver problem.

We have libpciaccess in Ubuntu, in the Universe repository. We build the Ubuntu packages with that disabled for now. We'll probably get it into main for Intrepid and start making it a build-time dependency like Debian does.

[Frode M. Døving (frode)]

I can not reproduce this with the vesa driver, because it doesn't do compositing.
However, I can not reproduce this display corruption with the i810 driver.

None of the packages at http://people.ubuntu.com/~bryce/bisect/ behaved different from the default hardy package, for me. The only package I have tested so far, with any improvement, is the one i backported from debian experimental.

I also tried the linux-rt kernel in hardy, without any difference.
I'm currently using the -generic kernel.

One thing worth mentioning is that the intel driver worked nicely in gutsy. This started directly after upgrading to hardy.
Could it be the xserver or anything?
I really doubt this is hardware related, Vista works flawlessly. But then again one doesn't change VTs in Vista. :)

(I'm not sure my issue is directly related to the description of this bug)

[Khashayar Naderehvandi (khashayar)]

I think I misunderstood the original post here. The vertical line is never a problem for me, because it's only visible before my laptop enters suspend, not only any VT switch (it might have been there sometimes on a normal VT switch, but has definitely disappeared after a couple of switches back and forth). What I'm saying, is that it has never been an actual problem for me.

That said, I'm quite sure this problem is caused by the i915 kernel module. I say this based on the fact that even before this problem appeared in Hardy, I tried drm modules from git (in order to find a solution to a suspend problem I had), and that's the first time I saw the vertical line. Variably booting with the git-drm modules and the hardy-shipped drm modules would either reveal the problem or not.

An easy way to test if my assumption is correct, is to boot with an old (perhaps gutsy?) kernel and see if the problem persists. (I'll do that myself if I find the time, but my real life is really getting out of control right now due to me hanging around too much at launchpad and similar sites :-p)

[Frode M. Døving (frode)]

I tested with the 2.6.22-14-generic gutsy kernel. No change. But, I also tested the KDE4 Kubuntu hardy livecd and it had no issues. Starting to think this is some leftover configs somewhere that broke from gutsy -> hardy.

[jhansonxi (jhansonxi)]

I'm working my way through some of the git builds from Bryce. These two both have the problem along with the latest today:
xserver-xorg-video-intel_2.1.0+git20070625.ccac60bf-1_i386.deb
xserver-xorg-video-intel_2.2.0+git20080102.0fd769b5-1_i386.deb

The ForceEnablePipeA option doesn't have any effect on it.
The problem seems to occur when X first loads. It usually happens with the first VT switch after gdm first starts and then again after login. It often disappears with subsequent VT switches and returns if I kill X. After gdm loads the effect is less severe - a small white box near the bottom-right corner of the screen. After Gnome loads it shows up as the long white line in the picture.

I also found out it happens in Fedora 9 beta on a Panasonic CF-51 with the same 855 chipset.

[jhansonxi (jhansonxi)]

So far I haven't been able to reproduce the problem with the vesa or i810 drivers.

[jhansonxi (jhansonxi)]

Fedora bug report: https://bugzilla.redhat.com/show_bug.cgi?id=441184

[Bryce Harrington (bryce)]

jhansonxi, I've forwarded your bug upstream to Xorg for their assistance with this issue. Would you mind please subscribing to the upstream bug report in case they have questions or need you to test something? Then you can provide the info directly without me slowing down the process.

Kashayar and Frode, while your symptom sounds similar to jhansonxi from what you've reported so far I suspect you may be having completely different issues. And since upstream doesn't like having multiple issues in one report, please file each of you file new bug reports and include similar info as jhansonxi so we can forward those as well.

[Bryce Harrington (bryce)]

jhansonxi, upstream believes this to be fixed in their git master tree. Could you please test xorg's git driver and verify?

[jhansonxi (jhansonxi)]

Do you happen to have a package for it in your PPA or maybe in hardy-proposed? I'm really busy right now and can't really afford to spend time trying to figure out how to build from freedesktop.org's git tree.

[jhansonxi (jhansonxi)]

I stumbled through a build following the X.Org Wiki guidelines here:
http://www.x.org/wiki/Development/git

I'm not sure I did it correctly. I only built xf86-video-intel and I had problems with the "export LD_LIBRARY_PATH=/opt/gfx-test/lib" not having any effect on which libs X was using. I ended up renaming the originals and using symlinks to the new ones.

The white lines are gone but now I see either black static (especially noticeable with Midnight Commander and aptitude) or with subsequent VT switching I have some text corruption like the scrollbar block in MC. In xorg.conf I have "ForceEnablePipeA" commented out and now see "underrun on pipe A" errors in Xorg.0.log. Re-enabling it eliminates the errors in the log but the other VT problem are still present.

[Bryce Harrington (bryce)]

jhansonxi, can you please subscribe to the upstream bug report at https://bugs.freedesktop.org/show_bug.cgi?id=15510 so you can respond to upstream's questions directly? Having me acting as a go-between for launchpad and bugzilla is only going to result in slowing the fix. ;-)

[Bryce Harrington (bryce)]

In the upstream bug report it sounds like the issue is no longer present. Please test with the 2.3.2 or newer version of -intel, and feel free to reopen this bug with additional details if the issue still exists for you.