Bug 15510

Summary:	[855GM] Persistent large vertical white line on VTs
Product:	xorg	Reporter:	Bryce Harrington <bryce>
Component:	Driver/intel	Assignee:	Wang Zhenyu <zhenyu.z.wang>
Status:	RESOLVED FIXED	QA Contact:	Xorg Project Team <xorg-team>
Severity:	minor
Priority:	medium	CC:	jhansonxi, michael.fu
Version:	7.3 (2007.09)	Keywords:	NEEDINFO
Hardware:	x86 (IA32)
OS:	Linux (All)
URL:	https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/210600
Whiteboard:
i915 platform:		i915 features:

Description Bryce Harrington 2008-04-14 18:52:21 UTC

I'm forwarding this bug from a Ubuntu reporter.

Ubuntu Bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/210600
RedHat Bug: https://bugzilla.redhat.com/show_bug.cgi?id=441184

"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 cannot be reproduced with the -vesa or -i810 drivers.

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."

PCI ID: Intel 82852/855GM Integrated Graphics Device [8086:3582, 1179:ff00]
Xorg.0.log: http://launchpadlibrarian.net/13039104/Xorg.0.log_pipea
Photo: http://launchpadlibrarian.net/13039087/vt_white_line.jpg

Comment 1 Wang Zhenyu 2008-05-07 18:44:06 UTC

Not sure if Jesse's patch helps on this, as I don't have 855 box to test, but good to try it, both on git master and xf86-video-intel-2.3-branch.

Comment 2 Wang Zhenyu 2008-05-25 18:33:45 UTC

Forgot to update this, I've tested it on a sony 855GM which seems fixed this issue as far as I do the test. Any update from reporter?

Comment 3 Michael Fu 2008-06-05 18:58:54 UTC

Bryce, any update from the bug reporter?

Comment 4 Bryce Harrington 2008-06-14 01:19:33 UTC

Yes, the reporter has tested against the git version, and reports:

"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."

Comment 5 Wang Zhenyu 2008-06-18 00:15:22 UTC

I've tested on one sony 855gm, which had such VT switch problem, and haven't seen this again with 2.3.2.
It's better to try 2.3.2 release.

Comment 6 Michael Fu 2008-06-22 19:27:31 UTC

Bryce, would you please ask your original bug reporter to test comment# 5? thanks.

Comment 7 Bryce Harrington 2008-06-27 18:29:57 UTC

Here is what he said:

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.

Comment 8 Jeff D. Hanson 2008-06-29 16:06:43 UTC

Sorry for the delay in response but I've been very busy.  I retrieved the git tree again on Friday, June 27 and built the drivers again.  Upon testing I didn't notice any change.  X was stable, no white lines but lots of black static in the consoles.  Oddly the X log showed the driver version as 2.2.0 but I retrieved and rebuilt it again and got the same version.

Comment 9 Wang Zhenyu 2008-06-30 00:12:17 UTC

yes, we haven't fixed master version yet, and current master might have regression with display arbitration control. So please first try 2.3.2 release.
Get it from http://xorg.freedesktop.org/archive/individual/driver/

Comment 10 Bryce Harrington 2008-07-03 18:00:04 UTC

Jeff, I've put the 2.3.2 driver into Intrepid in case you'd like to test against that (you can download an alpha-1 CD from the usual mirrors.)

Comment 11 Jeff D. Hanson 2008-07-04 07:42:09 UTC

I've built and tested the 2.3.2 version.  White lines are not evident but black static in VT is.  OpenGL games appear to be working normally.  In Ubuntu's recovery mode (non-graphical single user) no static is present.

I may try the Intrepid alpha this weekend if time permits.

Comment 12 Wang Zhenyu 2008-07-27 22:15:17 UTC

I haven't seen vertical while line on all 855s here for quite a long time, so I assume this is fixed. If there're other different symptom, pls open new bug.

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.