[915GM] font corruption on Intel GMA900

Bug #745608 reported by Zhmak on 2011-03-30
354
This bug affects 84 people
Affects Status Importance Assigned to Milestone
xf86-video-intel
Fix Released
High
xserver-xorg-video-intel (Debian)
Confirmed
Unknown
xserver-xorg-video-intel (Ubuntu)
Low
Unassigned

Bug Description

Sometimes getting incomplete drawing of same glyphs of one font on whole screen.

In the screenshot you can see the "e" is drawn incompletely (both english and cyrillic too).

The bug is happening frequently and spontaneous on my Asus EEEPC 900.

(This issue affects Ubuntu's 10.10 or later. A workaround using the DebugWait parameter is described in comment #40 - https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/745608/comments/40 ).

[lspci]
Nux: lspci: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592] (rev 04)

Zhmak (zhmak) wrote :
Bryce Harrington (bryce) on 2011-03-30
Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Confirmed
importance: Undecided → Low
Bryce Harrington (bryce) wrote :

Hi Zhmak,

Hmm, we've had a number of text corruption bugs however not one like this; and most of those have been resolved now. So this looks like it may be a new bug. Before I send this upstream, I have some questions for you:

1. When did you first start noticing this problem? E.g. did you recently update to 11.04 and start noticing it right away, or has it come on only recently?

2. You say it happens frequently. Do you notice any patterns to what makes it appear? E.g. certain programs you always have running, or certain activities you perform?

3. If you boot into Classic Desktop (no effects), can you reproduce the problem?

4. Could this simply be a bug in the font/language you're using? Can you try experimenting with different theme and language settings and note if you see it with other combinations?

Changed in xserver-xorg-video-intel (Ubuntu):
status: Confirmed → Incomplete
Zhmak (zhmak) wrote :

Hi Bryce,

1. Can't remember first occurrence. I'm sure that I saw it in Maverick, may be in Lucid. Second screenshot made in Maverick.
2. It happening few times at week. I can surf web with firefox or opening console, nothing unusual.
3. I'll switch to "no effects" mode to find it out.
4. I don't think so. Using only default themes and fonts. You can find that another font affected on second attached screenshot (monospace font on console) .

Also I saw thin grey (transparent?) streak on maximize button yesterday and same streak on close button while writing this reply. Can' take screenshot because changing focus to gnome-screenshot cause to change button color and streak disappear.

Thanks for attention!

Zhmak (zhmak) wrote :

Bug still appear in "no effects" mode.

I saw it in gnome-screensaver prompt of password to login. I didn't press any key and screen blackened due inactivity. After this I pressed key to bring it back - all glyphs drawn well.

bugbot (bugbot) on 2011-04-03
tags: added: corruption
Bryce Harrington (bryce) wrote :

Alright, thanks, I think all the info needed for sending this upstream has been gathered.

Changed in xserver-xorg-video-intel (Ubuntu):
status: Incomplete → Confirmed
Zhmak (zhmak) wrote :

I saw this bug again in gnome-screensaver unlock screen. At this time there are three different glyphs corrupted.

Description of the problem:
With the soon to be released distros graphical corruption occasionally appears on font characters - everywhere a corrupted character of that size is it will be corrupted the same way.

Steps to reproduce:
1. Start computer.
2. Start a gnome-terminal .
3. Type
echo "import string; print string.printable" | python
4. Press Ctrl-"+" several times.
5. Press Ctrl-"-" several times.
6. Go to step 4.

Expected results:
Text to look normal as it is resized.

Actual results:
Sometimes characters will appear to have a line through them.

How reproducible is the problem?
Somewhat reproducible but only on an EeePC 900.

Version information:
Ubuntu 11.04
xorg 1:7.6+4ubuntu1
xserver-xorg-video-intel 2:2.14.0-4ubuntu6
linux-image-2.6.38-7-generic 2.6.38-7.39

Fedora 15
xorg-x11-server-Xorg-1.10.0-7.fc15.i686
xorg-x11-drv-intel-2.14.0-4.fc15.i686
kernel-2.6.38.2-9.fc15.i686

00:00.0 Host bridge [0600]: Intel Corporation Mobile 915GM/PM/GMS/910GML
Express Processor to DRAM Controller [8086:2590] (rev 04)

Additional Information:
Unreproducible on a machine with a 945GM/GMS/GME, 943/940GML (rev 03)

Created attachment 45730
Screenshot of glyph corruption

As I'm only seeing this issue on LiveCDs (my Ubuntu 10.04 setup with an old xorg but a 2.6.38 kernel seems fine) testing fixes could be tricky for the foreseeable future...

I will also note this happens with gnome-shell, compiz or metacity (although it seems to happen a bit sooner/more frequently with gnome-shell and Unity desktops).

For 915GM it is important to test with 2.15.0 as well to rule out one source of tiling corruption.

A somewhat painful Ubuntu live CD upgrade to xserver-xorg-video-intel 2:2.15.0+git20 shows the same problem (Xorg.0.log shows it it is using 2.15.0 too)...

Thanks Sitsofe. I can now cry myself to sleep.

Some additional information (although I'm not sure how comforting it's going to be):

Ubuntu 10.10 also exhibits the same behaviour (but only after I switched from compiz to metacity) and has the following packages:
xorg 1:7.5+6ubuntu3
xserver-xorg-video-intel 2:2.12.0-1ubuntu5
linux-image 2.6.35.28.36

My Ubuntu 10.04 setup with a 2.6.38 kernel does not show the problem with the following packages:
xorg 1:7.5+5ubuntu1
xserver-xorg-video-intel 2:2.9.1-3ubuntu5

Another data point - the problem doesn't seem to occur with Fedora 13:
xorg-x11-server-Xorg-1.8.0-12.fc13.i686
xorg-x11-drv-intel-2.11.0-4.fc13.i686
kernel-2.6.33.3-85.fc13.i686

So it appears that the problem was inserted in the 2.12 release of the Intel DRM module / 2.6.34-2.6.35 release of the kernel.

(Numerous bisections later...)

The problem appears to have been introduced in the following commit:

commit f05dd2f09cac422c423dae8f9b8e2be13df05a8f
Author: Eric Anholt <email address hidden>
Date: Fri Feb 26 13:32:11 2010 -0800

    drm/i915: Don't bother with the BKL for GEM ioctls.

    We probably don't need it for most of the other driver ioctls as well,
    but we explicitly did locking when doing the GEM pieces. On CPU-bound
    graphics tasks, the BKL was showing up as 1-2% of CPU time.

    Signed-off-by: Eric Anholt <email address hidden>

I've narrowed it down to two lines in drivers/gpu/drm/i915/i915_dma.c:

       DRM_IOCTL_DEF(DRM_I915_GEM_SET_TILING, i915_gem_set_tiling, DRM_UNLOCKED),
       DRM_IOCTL_DEF(DRM_I915_GEM_GET_TILING, i915_gem_get_tiling, DRM_UNLOCKED),

If the last parameter is 0 instead of DRM_UNLOCKED the problem goes away even on the latest drm-intel-fixes branch.

Created attachment 45831
Workaround glyph corruption

It's blunt but it seems to work. I haven't done tests to work out if only one of the lines is needed...

Sadly the above patch did nothing to solve the problem on a Fedora 15 live CD. Rolling back to a 2.6.28 kernel with the above patch didn't help either. Weird and frustrating.

Bryce Harrington (bryce) wrote :

Can you confirm that you are still seeing this problem with the natty release?

If you are, can you test one more thing please - we are now providing builds of upstream's experimental driver and I'd like to confirm it also affects their code as well before we send this bug upstream. Please install the kernel and reboot onto it, reproduce the bug, and then attach a fresh 'dmesg > dmesg.txt' here. Thanks ahead of time!

Changed in xserver-xorg-video-intel (Ubuntu):
status: Confirmed → Incomplete
Zhmak (zhmak) wrote :

Yes, I still seeing this bug.

Couple hours ago I did upgrade packages to up-to-date versions and rebooted system. Then I saw in unlock screen two different glyphs are stroked (picture attached to post).

How can I install newest kernel or experimental driver?

My current kernel is:
$ uname -a
Linux eee-900 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux

Version of xserver-xorg-video-intel is 2:2.14.0-4ubuntu7

Download full text (4.1 KiB)

Bryce,

I don't know if you received this feedback on the bug from Zhmak (it
was emailed only to me) so I am forwarding it to you.

---------- Forwarded message ----------
From: Zhmak <email address hidden>
Date: Fri, Apr 22, 2011 at 2:50 AM
Subject: [Bug 745608] Re: font corruption on Intel GMA900
To: <email address hidden>

Yes, I still seeing this bug.

Couple hours ago I did upgrade packages to up-to-date versions and
rebooted system. Then I saw in unlock screen two different glyphs are
stroked (picture attached to post).

How can I install newest kernel or experimental driver?

My current kernel is:
$ uname -a
Linux eee-900 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC
2011 i686 i686 i386 GNU/Linux

Version of xserver-xorg-video-intel is 2:2.14.0-4ubuntu7

** Attachment added: "stroked letters i unlock screen dialog"
  https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/745608/+attachment/2081933/+files/DSC04531.JPG

--
You received this bug notification because you are a direct subscriber
of a duplicate bug (742260).
https://bugs.launchpad.net/bugs/745608

Title:
 font corruption on Intel GMA900

Status in “xserver-xorg-video-intel” package in Ubuntu:
 Incomplete

Bug description:
 Binary package hint: xserver-xorg-video-intel

 Sometimes getting incomplete drawing of same glyphs of one font on
 whole screen.

 At screenshot you can see "e" drawn incomplete (both english and
 cyrillic too).

 That bug happening frequently and spontaneous on my Asus EEEPC 900.

 ProblemType: Bug
 DistroRelease: Ubuntu 11.04
 Package: xserver-xorg-video-intel 2:2.14.0-4ubuntu4
 ProcVersionSignature: Ubuntu 2.6.38-7.39-generic 2.6.38
 Uname: Linux 2.6.38-7-generic i686
 Architecture: i386
 CompizPlugins: No value set for
`/apps/compiz-1/general/screen0/options/active_plugins'
 CompositorRunning: compiz
 DRM.card0.LVDS.1:
  status: connected
  enabled: enabled
  dpms: On
  modes: 1024x600
  edid-base64:
 DRM.card0.VGA.1:
  status: disconnected
  enabled: disabled
  dpms: Off
  modes:
  edid-base64:
 Date: Wed Mar 30 14:44:17 2011
 DistUpgraded: Fresh install
 DistroCodename: natty
 DistroVariant: ubuntu
 GraphicsCard:
  Intel Corporation Mobile 915GM/GMS/910GML Express Graphics
Controller [8086:2592] (rev 04) (prog-if 00 [VGA controller])
    Subsystem: ASUSTeK Computer Inc. Device [1043:82d9]
    Subsystem: ASUSTeK Computer Inc. Device [1043:82d9]
 InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha i386 (20110321)
 MachineType: ASUSTeK Computer INC. 900
 ProcEnviron:
  LANGUAGE=ru_RU:en
  LANG=ru_RU.UTF-8
  SHELL=/bin/bash
 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-7-generic
root=UUID=75374be3-dac3-432a-946e-99728dd11078 ro quiet splash
vt.handoff=7
 Renderer: Unknown
 SourcePackage: xserver-xorg-video-intel
 UpgradeStatus: No upgrade log present (probably fresh install)
 dmi.bios.date: 03/03/2009
 dmi.bios.vendor: American Megatrends Inc.
 dmi.bios.version: 1006
 dmi.board.asset.tag: To Be Filled By O.E.M.
 dmi.board.name: 900
 dmi.board.vendor: ASUSTeK Computer INC.
 dmi.board.version: x.xx
 dmi.chassis.asset.tag: 0x00000000
 dmi.chassis.type: 10
 dmi.chassis.vendor: ASUSTek Computer INC.
 dmi.chassis.version: x.x
 dm...

Read more...

Download full text (4.0 KiB)

I booted a live CD of natty and did not see the problem. Do I need to
install to test?

On Fri, Apr 22, 2011 at 2:40 AM, Bryce Harrington
<email address hidden> wrote:
> Can you confirm that you are still seeing this problem with the natty
> release?
>
> If you are, can you test one more thing please - we are now providing
> builds of upstream's experimental driver and I'd like to confirm it also
> affects their code as well before we send this bug upstream.  Please
> install the kernel and reboot onto it, reproduce the bug, and then
> attach a fresh 'dmesg > dmesg.txt' here.  Thanks ahead of time!
>
> ** Changed in: xserver-xorg-video-intel (Ubuntu)
>       Status: Confirmed => Incomplete
>
> --
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (742260).
> https://bugs.launchpad.net/bugs/745608
>
> Title:
>  font corruption on Intel GMA900
>
> Status in “xserver-xorg-video-intel” package in Ubuntu:
>  Incomplete
>
> Bug description:
>  Binary package hint: xserver-xorg-video-intel
>
>  Sometimes getting incomplete drawing of same glyphs of one font on
>  whole screen.
>
>  At screenshot you can see "e" drawn incomplete (both english and
>  cyrillic too).
>
>  That bug happening frequently and spontaneous on my Asus EEEPC 900.
>
>  ProblemType: Bug
>  DistroRelease: Ubuntu 11.04
>  Package: xserver-xorg-video-intel 2:2.14.0-4ubuntu4
>  ProcVersionSignature: Ubuntu 2.6.38-7.39-generic 2.6.38
>  Uname: Linux 2.6.38-7-generic i686
>  Architecture: i386
>  CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
>  CompositorRunning: compiz
>  DRM.card0.LVDS.1:
>   status: connected
>   enabled: enabled
>   dpms: On
>   modes: 1024x600
>   edid-base64:
>  DRM.card0.VGA.1:
>   status: disconnected
>   enabled: disabled
>   dpms: Off
>   modes:
>   edid-base64:
>  Date: Wed Mar 30 14:44:17 2011
>  DistUpgraded: Fresh install
>  DistroCodename: natty
>  DistroVariant: ubuntu
>  GraphicsCard:
>   Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592] (rev 04) (prog-if 00 [VGA controller])
>     Subsystem: ASUSTeK Computer Inc. Device [1043:82d9]
>     Subsystem: ASUSTeK Computer Inc. Device [1043:82d9]
>  InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha i386 (20110321)
>  MachineType: ASUSTeK Computer INC. 900
>  ProcEnviron:
>   LANGUAGE=ru_RU:en
>   LANG=ru_RU.UTF-8
>   SHELL=/bin/bash
>  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-7-generic root=UUID=75374be3-dac3-432a-946e-99728dd11078 ro quiet splash vt.handoff=7
>  Renderer: Unknown
>  SourcePackage: xserver-xorg-video-intel
>  UpgradeStatus: No upgrade log present (probably fresh install)
>  dmi.bios.date: 03/03/2009
>  dmi.bios.vendor: American Megatrends Inc.
>  dmi.bios.version: 1006
>  dmi.board.asset.tag: To Be Filled By O.E.M.
>  dmi.board.name: 900
>  dmi.board.vendor: ASUSTeK Computer INC.
>  dmi.board.version: x.xx
>  dmi.chassis.asset.tag: 0x00000000
>  dmi.chassis.type: 10
>  dmi.chassis.vendor: ASUSTek Computer INC.
>  dmi.chassis.version: x.x
>  dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1006:bd03/03/2009:svnASUSTeKComputerINC.:pn900:pvr0704:rvnASUSTeKComp...

Read more...

Download full text (4.6 KiB)

While testing from the live CD the screen got totally garbled and the
machine crashed. I guess I should expect this with an alpha version.
I had to power cycle it. This happened after installing Chromium for
further testing (all in the Live CD).

On Fri, Apr 22, 2011 at 9:23 AM, Anthony Waitz <email address hidden> wrote:
> I booted a live CD of natty and did not see the problem.  Do I need to
> install to test?
>
>
> On Fri, Apr 22, 2011 at 2:40 AM, Bryce Harrington
> <email address hidden> wrote:
>> Can you confirm that you are still seeing this problem with the natty
>> release?
>>
>> If you are, can you test one more thing please - we are now providing
>> builds of upstream's experimental driver and I'd like to confirm it also
>> affects their code as well before we send this bug upstream.  Please
>> install the kernel and reboot onto it, reproduce the bug, and then
>> attach a fresh 'dmesg > dmesg.txt' here.  Thanks ahead of time!
>>
>> ** Changed in: xserver-xorg-video-intel (Ubuntu)
>>       Status: Confirmed => Incomplete
>>
>> --
>> You received this bug notification because you are a direct subscriber
>> of a duplicate bug (742260).
>> https://bugs.launchpad.net/bugs/745608
>>
>> Title:
>>  font corruption on Intel GMA900
>>
>> Status in “xserver-xorg-video-intel” package in Ubuntu:
>>  Incomplete
>>
>> Bug description:
>>  Binary package hint: xserver-xorg-video-intel
>>
>>  Sometimes getting incomplete drawing of same glyphs of one font on
>>  whole screen.
>>
>>  At screenshot you can see "e" drawn incomplete (both english and
>>  cyrillic too).
>>
>>  That bug happening frequently and spontaneous on my Asus EEEPC 900.
>>
>>  ProblemType: Bug
>>  DistroRelease: Ubuntu 11.04
>>  Package: xserver-xorg-video-intel 2:2.14.0-4ubuntu4
>>  ProcVersionSignature: Ubuntu 2.6.38-7.39-generic 2.6.38
>>  Uname: Linux 2.6.38-7-generic i686
>>  Architecture: i386
>>  CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
>>  CompositorRunning: compiz
>>  DRM.card0.LVDS.1:
>>   status: connected
>>   enabled: enabled
>>   dpms: On
>>   modes: 1024x600
>>   edid-base64:
>>  DRM.card0.VGA.1:
>>   status: disconnected
>>   enabled: disabled
>>   dpms: Off
>>   modes:
>>   edid-base64:
>>  Date: Wed Mar 30 14:44:17 2011
>>  DistUpgraded: Fresh install
>>  DistroCodename: natty
>>  DistroVariant: ubuntu
>>  GraphicsCard:
>>   Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592] (rev 04) (prog-if 00 [VGA controller])
>>     Subsystem: ASUSTeK Computer Inc. Device [1043:82d9]
>>     Subsystem: ASUSTeK Computer Inc. Device [1043:82d9]
>>  InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha i386 (20110321)
>>  MachineType: ASUSTeK Computer INC. 900
>>  ProcEnviron:
>>   LANGUAGE=ru_RU:en
>>   LANG=ru_RU.UTF-8
>>   SHELL=/bin/bash
>>  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-7-generic root=UUID=75374be3-dac3-432a-946e-99728dd11078 ro quiet splash vt.handoff=7
>>  Renderer: Unknown
>>  SourcePackage: xserver-xorg-video-intel
>>  UpgradeStatus: No upgrade log present (probably fresh install)
>>  dmi.bios.date: 03/03/2009
>>  dmi.bios.vendor: American Megatrends Inc.
>>  dmi.bi...

Read more...

I have the same issue with my eeePC 701 4G. After some time fonts begin to get corrupt.
I have a pictures wich i upload as attachment.

Maybe i can help, what can i do to give you more information?

Changed in xserver-xorg-video-intel (Ubuntu):
status: Incomplete → Confirmed

I'd like to confirm that this bug manifests itself for me as well, on an Asus EEE 900, on every recent distro I've tried. It's not only reproducible but happens all the time. It's extremely jarring, sometimes half the glyphs get corrupted resulting in barely readable text.

Sitsofe Wheeler (sitsofe) wrote :

I see this too. I've filed it upstream as https://bugs.freedesktop.org/show_bug.cgi?id=36326 .

Sitsofe Wheeler (sitsofe) wrote :

I forgot to say that I am using an EeePC 900 too and its chipset is an 915GM.

summary: - font corruption on Intel GMA900
+ [i915] font corruption on Intel GMA900
summary: - [i915] font corruption on Intel GMA900
+ [915GM] font corruption on Intel GMA900

The symptoms described in this bug are very similar to those described in the closed bug #34662 ...

This may also be related to bug #35557.

For what it's worth, there is some more anecdotal evidence that this was introduced in the 2.12 release of the Intel DRM module - http://forums.opensuse.org/english/get-technical-help-here/hardware/442680-font-corruption-x-anyone-else-seeing.html#post2272576 talks about how switching to intellegacy in OpenSUSE resolved the problem for the commenter. http://askubuntu.com/questions/29626/font-corruption-lines-through-characters talks about how it started happening in Ubuntu 10.10 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=600474#5 describes how it started happening after upgrading from xserver-xorg-video-intel 2:2.9.1-4
2:2.12.0+shadow-2 to xserver-xorg-video-intel 2:2.12.0+shadow-2
2:2.13.0-1 .

bug #35557 may or may not be related, but it's interesting that 1.) He's using a 945GM 2.) He's having vertical corrupted lines in glyphs. It seems that the 915GM only exhibits horizontal corruption (which by itself is very weird). By the way, it would be so great to finally put a nail in the coffin of this one, so please tell me if I can help with testing in any way.

Something possibly useful: switching the acceleration method from UXA to EXA seems to reduce the corruption significantly for me (one or two letters corrupted instead of a dozen), although unfortunately it's still there.

jules9112:
Bug #35995 sounds pretty much identical this bug (horizontal lines, 915GM, driver is 2.14+) and has been marked a duplicate of bug #35557 .

If someone who sees the problem can find a way of bisecting the intel driver versions between 2.11 and 2.12 we might at least be able to find out exactly which change introduced the problem. Once it has been narrowed down by a tester, the hope is that an expert can justify looking at the problem because finding a solution will hopefully take them less time than it would have done before...

bugbot (bugbot) on 2011-04-27
description: updated
Ferry Toth (ftoth) wrote :

Yes I have it too on Eepc 900 and also on desktop with 'Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)". All with Kubuntu.

See attachment following.

Had the same in Debian Squeeze. (same driver I guess, and older KDE).

Do not see the problem on Natty Kubuntu with Nvidia card.

Ferry

Ferry Toth (ftoth) wrote :
Ferry Toth (ftoth) wrote :

Check the 'v' in ex-yogi van de wijs

Some sizes look good, some not good.

Ferry Toth (ftoth) wrote :

And it's not just fonts, check these icons.

Robert Hooker (sarvatt) wrote :

Sorry for asking again, but do you have natty-updates enabled and 2:2.14.0-4ubuntu7.1 installed that you can test again with? It contains a fix that is relevant to this bug

Ferry Toth (ftoth) wrote :

Yes, I have natty-updates enabled and 2:2.14.0-4ubuntu7.1 installed.

The above screenshots were with the latest packages (natty-proposed not enabled).

I looks like the longer I have an application running the more distored the fonts. I can hardly read what I'm typing right now.

Could it be related to some font cache?

Ferry

Toucan (karmiktoucan) wrote :

I have the same bug on EEEPC900:
OS : Debian GNU/Linux
Kernel versions : 2.6.38-2-686 and 2.6.39-rc5
Drivers: xserver-xorg-intel 2.14.0 and 2.15.0-1

With Kernel 2.6.32-5-686 this bug doesn't appear.

On my system, this bug only seems to occur after resuming from suspend. Has anybody else here noticed a similar trend?

** My System **
PC: HP Pavilion dv1550se laptop
CPU: Intel(R) Pentium(R) M processor 1.60GHz
RAM: 1GB DDR400
Video: Mobile 915GM/GMS/910GML Express Graphics Controller
Sound: 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller
OS: Xubuntu 11.04 i386

Ferry Toth (ftoth) wrote :

No, on one system I never suspend. It seems more related to the time an application or the system is running.

BTW it also occured on Debian Squeeze with kernels earlier then 2.6.38. I am not sure but I think it got introduced with the intel driver 2.14.

Ferry

Toucan (karmiktoucan) wrote :

On my netbook (eeePC 900) with kernel 2.6.32-5-686 and intel drivers 2.14.0 or 2.15.0 this bug does not appear, but with newer kernels ( 2.6.38 or 2.6.39-rc5) there is corruptions.

I've just done an Ubuntu 11.04 install and tested with different kernels and I find 2.6.33 is OK, 2.6.34 is a problem. The bisection between .33 and .34 is as follows:

# bad: [e40152ee1e1c7a63f4777791863215e3faa37a86] Linus 2.6.34
# good: [60b341b778cc2929df16c0a504c91621b3c6a4ad] Linux 2.6.33
git bisect start 'v2.6.34' 'v2.6.33' '--' 'drivers/gpu/drm/i915/'
# good: [ae3db24aab398fb5f985696c12362eb12ef65812] drm/i915: extract fence stealing code
git bisect good ae3db24aab398fb5f985696c12362eb12ef65812
# bad: [8956c8bba5b11b3d3aec000e6c6184943011a8d4] drm/i915: Set up the documented clock gating on Sandybridge and Ironlake.
git bisect bad 8956c8bba5b11b3d3aec000e6c6184943011a8d4
# good: [1c62233508ef7104f8a78e571fdf5c72d0dc0200] Merge branch 'gpu-switcher' of /ssd/git//linux-2.6 into drm-next-stage
git bisect good 1c62233508ef7104f8a78e571fdf5c72d0dc0200
# bad: [71cf39b117d5aa817a4693f4478397e6b04bee25] drm/i915: Enable VS timer dispatch.
git bisect bad 71cf39b117d5aa817a4693f4478397e6b04bee25
# bad: [5d9391628e8eb3b0830697697a95bfd0c3c35b9e] drm/i915: remove an unnecessary wait_request()
git bisect bad 5d9391628e8eb3b0830697697a95bfd0c3c35b9e
# bad: [f05dd2f09cac422c423dae8f9b8e2be13df05a8f] drm/i915: Don't bother with the BKL for GEM ioctls.
git bisect bad f05dd2f09cac422c423dae8f9b8e2be13df05a8f

This is the same result as comment #8. Further, putting

Section "Device"
 Identifier "Intel 915GM"
 Driver "intel"
 Option "Tiling" "false"
EndSection

in /etc/X11/xorg.conf doesn't stop the problem from occurring.

Ferry Toth (ftoth) wrote :

Hmm, This problem seems to depend on the actual Intel chip:

eeepc 900: sometimes the broken fonts and other anomalies occur, restarting X seems to make them go away.
Chip set: VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)

asus mother board 1: always broken fonts, switching to different fonts or sizes can make the screen readable again.
Chip set: VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)

asus mother board2: no problems do far.
Chip set: VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 10)

All 3 systems running same Natty Kubuntu, 915GM and 82G33 in i386, 82945G in amd64.

Ferry

Ferry Toth (ftoth) wrote :

Given how badly readable the display is on 82945G I would say the importance should be higher then 'low'.

Sitsofe Wheeler (sitsofe) wrote :

Ferry:
Is the corruption that you see on the 945G the same as what you see on the EeePC/in the screenshot in comment #1 or is it slightly different?

Using a 2.6.36 kernel with Fedora 13 showed the problem. Using the 2.10 DDX driver with a newer kernel also showed the problem so it looks like this issue was masked with kernels <= 2.6.33. The thing to note is that Ubuntu 10.04 (with a 2.9 DDX) does not show the problem with newer kernels.

Ferry Toth (ftoth) wrote :

Yes, and no. I'm not using a dutch localization, so you I don't normally have Cyrillic fonts :-)

Also I'm using Kubuntu (though with evolution).

But both on Eeepc and 945G the problem is that fonts are broken. Each broken letter shows the same distortion as shown in screenshot $1 (where the 'e' is broken).

But the broken letters are not the same with each boot. Also in firefox when you increase the font size it changes and at a certain font size will go away.

With Eeepc the system is usable mostly, with 845G text can become totally unreadable.

Screen shots in #16 - #19 were taken on the 945G, but after I had been fiddling with changing the default kwin fonts, so it didn't even look so bad as normally. But after reboot the at first 'readable' font are again broken.

But as shown in screen shot #19 also icons are sometimes distorted (as you can see in the navigation iicons).

Ferry

dmiranda (dmiranda) wrote :

I have the same problem using Ubuntu natty completely updated.

Ferry Toth (ftoth) wrote :

This is related to bugzilla.kernel.org #26002.

I think.

Ferry

Sitsofe Wheeler (sitsofe) wrote :

Ferry:
It's really hard to tell and there's a risk that a lot of issues that might be need to be separate are lumped together.

I've seen different types of corruption on my EeePC 900 with an 915GM since 10.10:
Horizontal line(s) through a glyph. Affects the same character of that font/size repeatedly, problem persists past a repaint. Screenshot: https://bugs.freedesktop.org/attachment.cgi?id=45730
A rectangular/square "block" of the glyph is missing. Affects the same character of that font/size repeatedly, problem persists past a repaint. Probably the same as the above but might be different. Tends to be rarer than the first type of corruption.

The 945GM I have never shows the above problems (although it shows another issue - https://bugzilla.redhat.com/attachment.cgi?id=493733 ). I've also yet to see any font corruption on a machine with a 965G graphics chipset...

All the corruption above happens without needing to suspend/hibernate and resume.

We need to be clear on what types of corruption happen, where they happen, what triggers the corruption and which graphics card chipset is being used. Another thing to check is whether turning off tiling by putting

Section "Device"
    Identifier "Intel"
    Driver "intel"
    Option "Tiling" "false"
EndSection

in /etc/X11/xorg.conf and then rebooting changes whether the corruption appears (the above is purely for testing purposes though - don't run daily with such a configuration as it will be very slow!).

Ferry Toth (ftoth) wrote :

Sitofe,

Currently on my eeepc I see these both problems sporadically, but it is very workable, so I don't dare to complain.
I have had these same corruptions on the eeepc before. It seems to be coming and going with linux releases.

On the desktop with 945G at times ff becomes unreadable, until I press increase font size 2 times (ctrl-+).

Both problems you mention can be observed (exactly as you say, it affects a certain character/font/size combination, and eventually more and more become broken, switching to another size/font temporarily solves the problem), but the font problem is the most common and disturbing.

Note that while some complain about their terminal program, I don't see it in konsole (KDE terminal). This may be due to the font used?

So yes, I see the things you see, right now the 945G is affected most.

I can try tiling=false, and will report back.

But I don't know what else I can do. Any other suggestions?

Ferry

Sitsofe Wheeler (sitsofe) wrote :

Ferry:
I have good suggestions I'm afraid. Just out of interest, what CPU and which screen resolution is the 945G running at? How much RAM? I'm wondering if there's any sort of pattern to this problem...

Ferry Toth (ftoth) wrote :

Is there anyway I can automatically collect all relevant info as in the bug description?

Now I created a new bug report #785388. I can hardly believe that is the easy way.

Ferry

Sitsofe Wheeler (sitsofe) wrote :

Ferry:
Thanks for posting that. A quick glance shows the 945G machine is very different to the 915GM EeePC - it is using a 64 distro, has 4GBytes of memory the screen resolution is 1920x1200 connected by VGA etc. The only commonality I could see is that they are both ASUStek machines. Sigh.

Ferry Toth (ftoth) wrote :

The are both Kubuntu Natty using the Intel driver.

I could boot the 64-bit 945G with a 32-bit USB stick and see if that helps.

And I could switch temporarily to a lower resolution, but not 1024x600 I guess.

Actually the 64-bit machine has only 2GB of RAM not 4.

I'll report back with the results.

Ferry

Sitsofe Wheeler (sitsofe) wrote :

Ferry:
I would be surprised if 64 or 32 bit made a difference. Basically your results have ruled out that it's related to whether a 64 bit OS is used. Screen resolution difference also seem unlikely (I've reproduced the problem at 640x480 on my EeePC). I would be surprised if it is RAM related.

Ferry Toth (ftoth) wrote :

I think so too.

It will probably turn out to be related to the 945G chip, or if I am unlucky, to the revision of the chip.

But I have had these problems in the passed, and as the kernel got updated they went away again . Soi I am sure it can be done.

Ferry

Sitsofe Wheeler (sitsofe) wrote :

Ferry:
Can you test if having

Section "Device"
    Identifier "Intel"
    Driver "intel"
    Option "DebugWait" "true"
EndSection

in xorg.conf helps?

Ferry Toth (ftoth) wrote :

Sitofe,

I created an empty xorg.conf and pasted the lines exactly as above. Right now I have no artifacts as far as I can see (5 minutes ago I could hardly read the screen).

I must admit: 15 minutes ago I added to ppa's: ppa:kubuntu-ppa and ppa:glasen/intel-driver and then rebooted prior to following your advise.

That did not change anything. Not even the terrible frame rate I get with desktop effects enabled and the FPS widget enabled (2 fps). *Note that this does work for my Eeepc 900* which now has about 30 fps. 900MHz Pentium M beats Core 2 Duo 3GHz.

So it seem like DebugWait does the trick! Yeeah.

Thanks so much! Care to enlighten me why this works?

Ferry

Sitsofe Wheeler (sitsofe) wrote :

Ferry:
I actually don't know why it works :) Sadly I didn't get to that option by logical deduction but rather by trying everything I could... My guess is that there is a race happening where a buffer is being reused while it actually still in use. Here's what the intel man page says about the DebugWait option:

Option "DebugWait" "boolean"
Wait for the completion of every batch buffer before continuing, i.e. perform synchronous rendering.
Default: Disabled

So this changes from submitting batch buffers and *not* waiting for a reply to waiting for a reply after submitting each batch buffer (so effectively you can no longer simultaneously submit multiple batch buffers). This should also hurt speed as it is no longer possible to do so much at once so it's strange you are seeing a speed improvement...

There is also some slight evidence that this is a locking issue. Over on https://bugs.freedesktop.org/show_bug.cgi?id=36326#c8 I tried to find why certain old kernels don't show the issue and that narrowed down it down to a patch that removed the Big Kernel Lock (BKL) from various functions of the i915 driver presumably allowing more overlap.

Sitsofe Wheeler (sitsofe) wrote :

Ferry:
Does DebugWait improve things on the 945G too?

Ferry Toth (ftoth) wrote :

I need to clarify:
- the option does not improve speed
- updating KDE to 4.6.3 seems to improve speed on eeepc but not on 945G
- font problem on 945G completely goes away using DebugWait

- have not yet tested on eeepc.

Ferry

Ferry Toth (ftoth) wrote :

- on eeepc 900 it seems the font/glyph errors also disappear
- no noticeable speed deterioration

A quick recap:
Occurs with Intel DDX 2.10+ (tested up to .15) with Kernel 2.6.34+ (tested up to .39).
Reported affecting a 915GM and a 945G.
Setting

Section "Device"
    Identifier "Intel"
    Driver "intel"
    Option "DebugWait" "true"
EndSection

in xorg.conf works around the problem in at least two cases.
Setting Tiling to false in xorg.conf does not resolve the problem.

On my system (i915), I notice only a minor speed deterioration using the DebugWait command, observed in Aquaria (lower fps) and Snes9x (increased "hiccups"). The corrupted glyphs seem to be fixed for me as well using this workaround.

** My System **
PC: HP Pavilion dv1550se laptop
CPU: Intel(R) Pentium(R) M processor 1.60GHz
RAM: 1GB DDR400
Video: Mobile 915GM/GMS/910GML Express Graphics Controller
Sound: 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller
OS: Xubuntu 11.04 i386

Closing our bug https://bugzilla.redhat.com/708849 against this one.

OK I finally had time to test the SNA branch up at http://cgit.freedesktop.org/~ickle/xf86-video-intel/ . The only thing changed from a Fedora 15 live CD was the intel_drv.so .

The good news
This didn't show the corruption on font resizing at the terminal.

The bad news
While just typing at the terminal the entire prompt would sometimes disappear. Sometimes only one pixel of row of letters could be seen. When doing printscreen to try and capture a screenshot everything would fix itself just before the screenshot was taken. After a bit the entire system would lock up and the hangcheck timer would elapse. VTs and plymouth continued to work though. All this behaviour happens fairly quick - within 5 minutes of starting X.

Sitsofe, just to be a nuisance, can you try again with xf86-video-intel.git and --enable-sna

And then attach the usual the suspects (Xorg.log and i915_error_state), thanks!

Created attachment 47554
Xorg log taken after crash

Mainline xf86-video-intel.git still blows up.

Created attachment 47555
i915_error_state after crash

Created attachment 47556
Use pot size, not multiple-of-two tile height

Created attachment 47558
i915_error_state for 3.0.0-rc1 (without pot patch)

Created attachment 47559
i915_error_state for 3.0.0-rc1 (with pot patch)

Created attachment 47560
Fix unfenced alignment on pre-g33

Created attachment 47561
915_error_state after fix unfenced alignment on pre-g33 patch

Created attachment 47563
915_error_state after Y-tiling DDX patch

The combination of an updated SNA based DDX and the latest kernel patch seems to resolve all font corruption problems I have been seeing. However copying the binary DDX compiled for Fedora 15 to an Ubuntu 11.04 install showed that corruption around the border of the screen was happening when show all desktops (windows-s) was used (probably unrelated to this bug though).

Note: the kernel patch alone is not enough to stop font corruption.

The more I think about this, the more I feel this bug report should be marked fixed as soon as all the patches in it land - the latest intel.git + kernel changes fix the font problem but at a price. The DDX SNA rewrite has brought new issues (which should be in separate bug reports as they may be unrelated to this one) that make for an unpleasant experience at present.

Before this bug is closed I guess it is worth checking: is it possible for a patch to be generated for pre SNA xorg drivers/older kernels (as found in Ubuntu 11.04/Fedora 15)? If not, users seeing the font problem on said distros will have to use the DebugWait workaround until newer distros (11.08/16) land...

Yes, I'm planning to disable tiling on pre-G33 boxes without the kernel patch. That should prevent the hang (but at a noticeable performance hit). Sorry.

Sitsofe, please file those SNA bugs soon. :)

SNA rewrite issues have been broken out into bug 38021 . If I ever find the time I will try and split that bug into smaller pieces...

The workaround (comment #40) works for me too (Ubuntu 11.04 32-bit classic mode no effects, EeePC 900, Intel 915GM).

There is a rumour going round that this is actually Bug #28798 . I haven't had a chance to confirm or deny this...

A patch referencing this bug report has been merged in Linux v3.0:

commit e28f87116503f796aba4fb27d81e2c3d81966174
Author: Chris Wilson <email address hidden>
Date: Mon Jul 18 13:11:49 2011 -0700

    drm/i915: Fix unfenced alignment on pre-G33 hardware

Märt Põder (boamaod) wrote :

I add three pictures of this bug on my 2 different computers, laptop and desktop. It seems to me that the bug often becomes effective after system has suspended and activated again or different users logging on/off the system running/killing their applications.

Both systems have Ubuntu 11.04, xserver-xorg-video-intel version on both systems is 2:2.14.0-4ubuntu7.1, according to lspci desktop has 82945G/GZ and laptop has 915GM/GMS/910GML. Laptop occasionally shows slight corruption, however desktop gets heavily corrupted and this doesn't affect only fonts, as it may seem in the beginning.

Märt Põder (boamaod) wrote :
Märt Põder (boamaod) wrote :
Sitsofe Wheeler (sitsofe) wrote :

(Subscribing tabbernuk to this bug)

tabbernuk:
Does the workaround described in comment #40 reduce the problem for you? You may also want to test out the updated package in Bug 803012 ...

Märt Põder (boamaod) wrote :

I installed the update package 2:2.14.0-4ubuntu7.2 from natty-proposed and it seems to make things better. At least on my laptop (915/910) I haven't noticed corruption since upgrading the package (but this may change in time, I cannot be sure).

But it's different on my desktop (945), where the new package probably reduces the problem, but it still appears in previous form after some time. When I set Tiling=false it reduces corruption a lot, but there still appears some like before. Although I did notice it only in Ubuntu menu bar (submenus were fine). When I set DebugWait=true instead of Tiling=false, some of the games started doing a lot of "hiccups" and were practically unusable (I tried teeworlds from GetDeb). Some corruption appeared but was very episodical, by now I have noticed it only on GDM logon background image. I'd say, for me Tiling=false seemed a better workaround, because it didn't ruin the gaming experience and I didn't notice too much slowing down.

Märt Põder (boamaod) wrote :

Just after writing that I noticed font corruption on my laptop (915/910) login screen. I haven't set anything in xorg.conf on my laptop though. If the corruptions have really been reduced, only time will tell, it certainly seemed so at the beginning. But they have not been removed by the new package or workarounds, that's for sure. DebugWait=true doesn't seem a viable option for me, because it renders some of the graphically more demanding programs unusable.

Thanks for the efforts though. If you have any suggestions how and what more to test, I'm willing to help.

Sitsofe Wheeler (sitsofe) wrote :

tabbernuk:

Hmm it sounds like you have different bug to that described here (e.g. you see corruption in things other than text). I would suggest opening a separate (new) bug report (and then post a link to the new report here) because if the bug I see is fixed your issue can remain open if it continues...

Märt Põder (boamaod) wrote :

In #3 there are mentioned that window buttons display some kind of streak, but taking screenshot is not possible. I'm providing a screenshot of it on my Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04) on Ubuntu 11.04.

Sitsofe Wheeler (sitsofe) wrote :

tabbernuk:

I recommend filing a new bug report using https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+filebug . While your issue looks similar to this bug report, you are seeing corruption in things that are not glyphs so your issue is different to this one...

Please post a link to your new bug report back here though!

Märt Põder (boamaod) wrote :

Sitsofe:

I reported the bug on my i945 with the desktop etc corruption at https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/820881

However I suppose the bug on my i915 is the same one as described here, because I see mainly font corruption. Window buttons are a small exception which is quite hard to notice, but this was also reported in the original bug report on i915. I believe these reports belong together, because they both consist of similar defects (extra vertical lines on small sprites). Or do you suppose there should be also separate bug report on window buttons for i915?

And I want to stress that I didn't have the font corruption problem on Ubuntu 10.10 (and before), or at least it didn't happen often enough for me to notice it (although I still think I have seen it couple of times during past years).

Just a note that e28f87116503f796aba4fb27d81e2c3d81966174 does not appear to have any effect for me. I'm running a 3.0 kernel (with the 3.0.1 queue applied), have verified that the patch is included, and I still see the corruption.

For reference, this is i945:

00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Device 817a
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at dfd00000 (32-bit, non-prefetchable) [size=512K]
        I/O ports at b800 [size=8]
        Memory at c0000000 (32-bit, prefetchable) [size=256M]
        Memory at dfd80000 (32-bit, non-prefetchable) [size=256K]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
        Capabilities: [d0] Power Management version 2
        Kernel driver in use: i915
        Kernel modules: i915

X driver is the stock Fedora 15 version: xorg-x11-drv-intel-2.15.0-5.fc15.x86_64. I'll try the 2.15.901 code next just to see what happens.

Just to be thorough, I'll report that updating to server version 10.1.99.1 and Intel driver version 2.15.901 does not appear have any effect at all on the problem.

However, according to other information on this ticket I'd expect to see this problem on Fedora 14 (with xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64 and kernel-2.6.35.13-92.fc14.x86_64) but everything is completely fine there. That F14 kernel does, however, carry a few i915-related patches; I'm not able to tell if they have any bearing on the issue.

Regardless, this looks like an annoyingly complex issue.

Jason:

The kernel patch alone does not fix the problem (see comment #31). I needed an intel driver that was using the "new" SNA paths in addition to the kernel patch for the problem to be solved. This is consistent with what you are reporting because Fedora 15's intel driver is not using the SNA path (the SNA path isn't on by default in the intel drivers). If you can get hold of SNA enabled drivers for Fedora 15 let me know as I'd like to test them too (at the moment I have to hand compile has issues with older xorgs)...

I admit I am baffled by the fact that you do not see the problem on Fedora 14 though. Perhaps you are using a different desktop in Fedora 15 to what you were using in 14?

Oh and does the workaround described in comment #19 make any difference to your problem?

Unfortunately I am not entirely sure how to get an SNA-based DDX; I assumed that the 2.15.901 driver would be such, but perhaps that needs to be enabled at build time.

I can state that if this problem is present on F14, I haven't seen it and no user has reported it. I have 30+ identical desktops with this hardware configuration. It is certainly possible that some other difference masks the problem in F14; there is plenty of updated software and unfortunately you can't just go back to the old kernel and X on an F15 machine to check. Both logins are with the same account to a generic KDE desktop and it's pretty trivial to make it happen on the F15 machine; many times it's even visible on the login screen.

I might be able to take an F14 machine and go forward with X and the kernel to see if one breaks; I can try to allocate some time to try that out next week.

As for the debugwait trick, I'll try that out today if I can find some time.

OK, in my testing the DebugWait trick appears to work fine (with the 3.0.1 kernel and the 2.15.901 non-SNA driver, at least; I haven't time to drop back to the stock F15 packages today). I guess it's slower but I don't really notice much difference.

I can try a SNA build next week; I expect that it will solve the problems but I'm not sure if it's supposed to be ready for deployment yet.

Dominik Psenner (dpsenner) wrote :

Hooray, looks like I finally found the bug where I can submit the information I gathered. Two screenshots right away:

http://i.stack.imgur.com/Cfd9B.png
http://img835.imageshack.us/img835/8831/oddfonts2.png

I've got here a IBM X41t with intel GMA900 chipset:

~$ lspci |grep Display
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)

So, bug confirmed from my side and I would REALLY love that this issue gets a higher priority. My laptop is in a unusable state as I'm unable to read any longer text without getting headache after some time. I'm going to test Option "DebugWait" "true" and feed back the results ASAP.

Dominik Psenner (dpsenner) wrote :

Looks just like this solved the issues for me:

~$ cat /usr/share/X11/xorg.conf.d/10-monitor.conf
Section "Device"
    Identifier "Intel"
    Driver "intel"
    Option "DebugWait" "true"
EndSection

But it may need further testing. I'm going to feed back if the problem still occurs in the next days.

Sitsofe Wheeler (sitsofe) wrote :

(Subscribing dpsenner to this bug)

Dominik:
It's cool when you find a bug report that might help you fix a problem isn't it? :-)

Speaking as a random person on the Internet (I don't work for Canonical, Intel etc), it's very unlikely that you can have a bug's priority raised by asking (although subscribing/marking a bug as also affecting you is useful as it makes it clear how many people are interested in a given bug). The general reason is that while the bug may be massively disruptive for you, there are finite resources to go into fixing problems. If more people are seeing another issue just as major or more significant in some manner, then it is likely the resources will be put into solving that issue.

Of course, I would like to see this particular bug resolved too :). If this turns out to be your issue (your card's id looks the same as others that see this issue so chances are high), you can read further discussion in the upstream bug report: https://bugs.freedesktop.org/show_bug.cgi?id=36326 .

To answer Ferry's question about why the fix works: one of the Intel developers mentioned that this era of graphics cards have constraints related to tiling and DebugWait disabled tiling entirely (but another issue meant that "Tiling" "false" did not disable tiling(!)). It was only in later versions of the X drivers that tiling was actually used tiling, so that's why users with old Xorgs don't see this issue.

Dominik Psenner (dpsenner) wrote :

I strongly believe that the big average of the users who are having this same problem are unable to find this page (since the issue is hard to explain) and are thus unable to workaround the issue. I myself have spent 2 days searching - which speaks for itself, doesn't it?

So even if the package maintainers only decide to automatically activate DebugWait on these cards by default it would be a great improvement that would solve all future problems.There should be enough code already present in the automatic configuration detection logic of Xorg to add this small check with a few lines of code. Though, I'm not a package maintainer nore do I know how it works. Thus my estimates are surely not the best.

All summed up: just hack it so that it works for the masses. Nobody who got a intel GMA900 chipset cares for performance anyway, which means nobody would ever complain anymore.

thinkpad (fellowsgarden) wrote :

will it "go away" in oneiric?

is DebugWait the way to go? noticeable side-effects? slow-down??

I'm on a Thinkpad x41, and 2nd Dominik P's view that most people affected won't find out about DebugWait for a while, as it's not an easy google.

tp.

Dominik Psenner (dpsenner) wrote :

I've not observed any noticeable/negative side effects.

Sitsofe Wheeler (sitsofe) wrote :

(Still here in Oneric.

Version information:
Ubuntu 11.10
libdrm-intel1 2.4.26-1ubuntu1
xserver-xorg-video-intel 2:2.15.901-1ubuntu2
)

Ferry Toth (ftoth) wrote :

I have a mixed story when upgrading to Oneric:

Solved: eeepc 900, Chip set: VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)
Solved: asus mother board, Chip set: VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 10)

Problem persists: asus mother board, Chip set: VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02).

Ferry

thinkpad (fellowsgarden) wrote :

upgraded from Natty to Oneiric: font corruption occurs (after a short while, on a given website ... )

problem persists in Oneiric.

now I'm going to try "DebugWait" as described above... hope it'll work :-)

tags: added: 11.10 oneiric
Aibara Iduas (aibaraiduas) wrote :

I have a Sony SZ-450 (VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)), and experienced slight corruption starting with Ubuntu 10.10. Still present in 11.10, though the "DebugWait" solution also, thankfully, still works. I've noticed no speed difference when I use it, but I don't do too many graphically intensive things.

Aibara Iduas (aibaraiduas) wrote :

Unfortunately as of last week (or earlier this week?) I started noticing the corruption again in Oneiric, despite the "DebugWait" workaround. Not sure if some update broke things.

luca (llucax) wrote :

Option "DebugWait" "true" trick worked for me too:

00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)

Andre (ajx) wrote :

Font corruption does only affect some fonts - not all. I've never experienced the corruption when using Chromium, when observing the same webpage scrambled in Firefox.

I've never experienced this font corruption on pre-Natty releases (I skipped Maverick). The first time I suffered from corrupted fonts was on Natty using Unity 3D.

I'm wondering if this corruption can be related to the Ubuntu font? Or an interplay of Ubuntu font and Unity 3D?

I'm using Oneiric with all updates installed as of today on IBM Thinkpad X41 with the following output of 'lspci':
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)

I'm with IBM X41 tablet and have same problem. lspci give me the follow:
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)

I agree with Dominik P (dpsenner). It's hard to define this problem. I found this bug after few days of searching. So I assume out there they are many more people with this problem. I thing it should have higher importance.

m (anonymouser) wrote :

The font corruption not only affects some fonts but not others, and some letters, but not others, but some sizes and not others as well. if a webpage has unreadable fonts, increase the page magnification a few times and it will go away at higher pt sizes.

For me, the desktop graphic also gets corrupted.

m (anonymouser) wrote :

Another example

Dominik Psenner (dpsenner) wrote :

Your samples are far worse than what I experienced. To me only a few letters became barely readable because of strokes in them. However, it looks as if the freedesktop guys have been working on a solution in august 2011 (see remote bug watches). Let's hope that they were able to fix it.

burli (mb-embedit) wrote :

I have this problem after I wake up the laptop from standby. I have some broken letters, but also graphical errors on websites.

Alan Jenkins (aj504) wrote :

Thanks for the DebugWait workaround, Sitsofe. (EeePC 701 here).

Silas S. Brown (ssb22) wrote :

The DebugWait workaround worked for me on an EeePC 900 using Ubuntu 11.10. I added it to /usr/share/X11/xorg.conf.d/11-evdev-quirks.conf as there weren't any xorg.conf files in /etc.

Silas S. Brown (ssb22) wrote :

Actually the problem has not completely disappeared after the DebugWait workaround. But it does seem to be much less frequent.

Sean Channel (sean-channel) wrote :

'debugwait' fixed the problem for me on eeepc900 both w/ 512M & upgraded 2G ram, no swap in any case.

Bryce Harrington (bryce) wrote :

Could someone who experiences this problem please see if you can reproduce it in Precise? If so, please add the tag 'precise' to this bug and I can re-escalate it directly with Intel.

You might be able to test it by simply booting a LiveUSB image. Isos can be obtained at cdimages.ubuntu.com.

Changed in xserver-xorg-video-intel (Ubuntu):
status: Confirmed → Incomplete

I can confirm this bug still exists using Precise Alpha 2 from LiveUSB. After suspending once then resuming, I got immediate font corruption in Firefox.

** My System **
PC: HP Pavilion dv1550se laptop
CPU: Intel(R) Pentium(R) M processor 1.60GHz
RAM: 1.5GB DDR400
Video: Mobile 915GM/GMS/910GML Express Graphics Controller
Sound: 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller

tags: added: precise
Changed in xserver-xorg-video-intel (Ubuntu):
status: Incomplete → Triaged
Changed in xserver-xorg-video-intel:
importance: Unknown → High
status: Unknown → Confirmed
swaaye (swaaye-gmail) wrote :

I have an EeePC 900 (GMA 900) and am seeing this font corruption. I've tried a number of Linux distros in the past week and settled on Ubuntu 10.04 LTS because it is free of the issue. The newest I tried was unreleased Mint 13 "Precise"-based and it still has the problem.

10.04 LTS currently uses the 2.9.1 version of the Intel xorg module on kernel 2.6.32-39.

Ruokoton (uborealis) wrote :

00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)

xserver-xorg-video-intel:
  Installed: 2:2.17.0-1ubuntu4
  Candidate: 2:2.17.0-1ubuntu4
  Version table:
 *** 2:2.17.0-1ubuntu4 0
        500 http://fi.archive.ubuntu.com/ubuntu/ precise/main i386 Packages
        100 /var/lib/dpkg/status

Font corruption is back for me too - didn't notice it being there for a while, but now large chunks of various letters are missing. Only in terminal though. Browser, etc seem unaffected.

Andre (ajx) wrote :

For me the font corruption has become much better on IBM Thinkpad X41 since November 2011. Even after sending the the laptop to standby for several time, I get hardly corruption.

00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)

Package: xserver-xorg-video-intel
Status: install ok installed
Priority: optional
Section: x11
Installed-Size: 972
Maintainer: Ubuntu Developers <email address hidden>
Architecture: i386
Version: 2:2.15.901-1ubuntu2.1
Provides: xorg-driver-video

I can confirm that the issue is still occurring (and is reproducible within 30 seconds using the original steps) in the Fedora 17 and Ubuntu 12.04 betas (which are using v2.18 and v2.17 of the intel driver). The DebugWait option still resolves the problem too. None of the other options (DebugFlushBatches or DebugFlushCaches true, Tiling false) resolve the issue.

Using xorg-edgers ( https://launchpad.net/~xorg-edgers/+archive/ppa ) and sarvatt's intel-sna branch ( https://launchpad.net/~sarvatt/+archive/intel-sna ) also resolves the issue.

Morlok8k (aoa-supercool) wrote :

I have this bug on my eeePC 702 (8gb) running 12.04 and I've had it since 9.10 or 10.04. definitely on 10.10. even had it on Linux Mint 11 when i tried that.

I cant recall if i saw it in 9.04...

Dee (dmusil-x) wrote :

Reproducible on NB DELL Latitude D420 with Ubuntu 12.04 Precise

lspci |grep -i vga tells: 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

Please fix this hell or provide workaround, all applications have missing lines in the fonts, from terminal window to presentations and that does not look good but strange.

Sean Channel (sean-channel) wrote :

It's like my computer is running out of toner. I get this font corruption everywhere unless I use this workaround: add debug options for intel driver by creating the file "/usr/share/X11/xorg.conf.d/20-intel.conf" with the following contents:

Section "Device"
    Identifier "Intel"
    Driver "intel"
    Option "DebugWait" "true"
    Option "SwapbuffersWait" "false"
EndSection

description: updated
cablop (cablop) wrote :

Sean, unfortunately that fix is not working on my machine.

Font corruption still happens no matter what DE i decide to use, KDE, Gnome3, Unity, XFCE, LXDE... I didn't test Enlightenment, but it don't expect enything else but the same bug.

In my opinion this is an issue of Xorg and not the driver, because problems started to arise in the last update of Xorg.

cablop (cablop) wrote :

Does bug 378794 have a relationship with this bug?

Dee (dmusil-x) wrote :

cablop, no does not look similar. But definitely there is more than one bug - we have found a bug's nest. :c)

The bad thing is those devices were working correctly with the previous
versions of Xorg... I think the problem is in the xorg thing and not
exactly in the driver... except that was a dormant failure never faced
before...

On 2012 May 07, Monday 08:39:23, Dee wrote:
> cablop, no does not look similar. But definitely there is more than one
> bug - we have found a bug's nest. :c)
>

--
Hebert Caballero
http://cablop.info

In the Red Hat Bugzilla this issue is reported as #704959 [1].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=704959

(In reply to comment #44)
> The Debian BTS contains the following two reports regarding this issue.
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614296
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675734

As written in the Debian reports using the SNA backend fixes this issue on my Eee PC 701 4G system.

There are also some reports suggesting this happens with 945GM/GMS too.

Could the bug title be updated please to reflect that please?

In #intel-gfx Chris Wilson also suggested to try the options

    Option "DebugFlushBatches" "1"

and

    Option "DebugFlushWait" "1"

together and separately with the default backend (non SNA). Maybe someone in here can report any success with this.

15:08 < danvet> PaulePanter, could be swizzling corruption, we've fixed such a bug for i915g recently I think
15:09 < danvet> 3.4 should have the fix, so retesting with that one might be worth a shot

Could someone please try Linux kernel 3.4 and also 3.5? In Debian they should be in the experimental repositories and also on snapshot.debian.org [1]. Due to disk space limitations it is not very feasible on the Eee PC 701 4G.

Please remember to increase the appropriate log levels [2].

[1] http://snapshot.debian.org/package/linux/3.4.4-1~experimental.1/
[2] http://intellinuxgraphics.org/how_to_report_bug.html

As mentioned earlier Ubuntu 12.04 with intel drm 2.17 doesn't see any change in the issue when using DebugFlushBatches. DebugFlushWait isn't a recognised option.

(In reply to comment #50)
> As mentioned earlier Ubuntu 12.04 with intel drm 2.17 doesn't see any change in
> the issue when using DebugFlushBatches.

Alright. I have to test this.

> DebugFlushWait isn't a recognised option.

I am sorry. This should be `DebugWait`. I should have checked the manual `man intel`.

(In reply to comment #43)
> I can confirm that the issue is still occurring (and is reproducible within 30
> seconds using the original steps) in the Fedora 17 and Ubuntu 12.04 betas
> (which are using v2.18 and v2.17 of the intel driver).

This issue is also reproducible with xserver-xorg-video-intel 2:2.19.0-4.

> The DebugWait option still resolves the problem too.

I just tested that and it also seems – only one try – to solve this problem on my Eee PC 701 4G system.

> None of the other options (DebugFlushBatches or DebugFlushCaches true,
> Tiling false) resolve the issue.
>
> Using xorg-edgers ( https://launchpad.net/~xorg-edgers/+archive/ppa ) and
> sarvatt's intel-sna branch ( https://launchpad.net/~sarvatt/+archive/intel-sna
> ) also resolves the issue.

Does that automatically enable SNA? Can you just try the intel-sna? In (at least) 2.19.0 you can also enable SNA by an option to the driver (in Debian).

    $ more /etc/X11/xorg.conf.d/99-custom.conf
    Section "Device"
         Identifier "Device0"
         Driver "intel"
         Option "AccelMethod" "sna"
    EndSection

On #intel-gfx suggested having to use `DebugWait` is an indicator of a Linux kernel bug.

    20:34 < ickle> that hints towards a kernel bug
    20:34 < ickle> of the sort fixed by the unfenced blt patch

This should be in Linux 3.4 and definitely in 3.5. So it would be great if somebody could test this.

I agree that SNA resolves the issue (see comment #31).

I've just tested a 3.5 kernel with Ubuntu 12.04's 2.17 DDX and the issue remained (so newer kernels alone don't seem to help).

Mark Alan (malan) wrote :

Reproducible while running Xubuntu 12.04 on the following HW:
Asus P5LD2-VM Mainboard:
   VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
   Subsystem: ASUSTeK Computer Inc. Device 817a
   Kernel driver in use: i915
   Kernel modules: intelfb, i915

Hi,

Paul Menzel wrote:
> On #intel-gfx suggested having to use `DebugWait` is an indicator of a
> Linux kernel bug.
>
> 20:34 < ickle> that hints towards a kernel bug
> 20:34 < ickle> of the sort fixed by the unfenced blt patch
>
> This should be in Linux 3.4 and definitely in 3.5. So it would be great
> if somebody could test this.

JFTR: I experienced this bug definitely on my EeePC 701 4G with kernel
3.4 (currently 3.4.4-1~experimental.1) from the moment it hit Debian
Experimental until I switched to sna, i.e. for months.

Using sna had strange side-effects like wrong tint colors in urxvt:
blue, cyan and 100% transparency instead of 50%, i.e. clear instead of
shaded. After X start I always had blue, after adding another screen
via xrandr, I got 100% transparency, after removing that screen again,
I had cyan.

So far I haven't noticed any font corruption since the switch to sna,
also not after suspend to RAM (which was suspected somewhere else to
trigger the corruption).

  Regards, Axel
--
 ,''`. | Axel Beckert <email address hidden>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
  `- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5

Changed in xserver-xorg-video-intel (Debian):
status: Unknown → Confirmed

Still happens on fedora 17.

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
kernel-PAE-3.6.2-4.fc17.i686
xorg-x11-server-Xorg-1.12.3-2.fc17.i686
xorg-x11-drv-intel-2.20.8-1.fc17.i686
mesa-dri-drivers-8.0.4-1.fc17.i686

With sna accel X crashes occasionally.

(In reply to comment #55)
> With sna accel X crashes occasionally.

Tell me more. New bug, and make sure you have 2.20.12.

(In reply to comment #56)
> (In reply to comment #55)
> > With sna accel X crashes occasionally.
>
> Tell me more. New bug, and make sure you have 2.20.12.

Unfortunately fedora 17 has only 2.20.10 in updates-testing. Have to compile myself then.

According the changelog there are no changes related to sna in 2.20.11 and 2.20.12, but 2.20.10 are still crashing. It happens when closing nomachine nx client window, for example. Should I test and report with 2.20.12 anyway?

(In reply to comment #58)
> According the changelog there are no changes related to sna in 2.20.11 and
> 2.20.12, but 2.20.10 are still crashing. It happens when closing nomachine
> nx client window, for example. Should I test and report with 2.20.12 anyway?

I mentioned that there was a fix for a potential crash in 2.20.12 which being the only reported at the time I'm optimistic that it is also the one afflicting you.

(In reply to comment #59)
> I mentioned that there was a fix for a potential crash in 2.20.12 which
> being the only reported at the time I'm optimistic that it is also the one
> afflicting you.

Built 2.20.12 - still the same :( I can try to rebuild with --enable-debug=full, open a new bug and provide more details, but tomorrow.

Ferry Toth (ftoth) wrote :

For me using sna in Quantal Kubuntu solved the problem.

I also have the impression that my screen update rate with 'desktop effects' is higher.

Win - win.

Ferry

Sean Channel (sean-channel) wrote :

Ferry,

Could you please post some more detail? What is sna? What libs & drivers are you using? E.g. mesa / opengl, intel video, vaapi..

I'm just trying to shine up my own quantal desktop here. Thanks much!

Ferry Toth (ftoth) wrote :

Hello Sean,

Like I said, using Quantal. You can easily lookup the versions in packages.ubuntu..com.

To use sna (Sanday Bridge New Acceleration) I created and xorg.conf containing:

Section "Device"
 Identifier "Card0"
 Driver "intel"
 Option "AccelMethod" "sna"
EndSection

(courtesy https://launchpad.net/~glasen/+archive/intel-driver).

Ferry

Any update? Maybe the latest one is fixed after all?

Changed in xserver-xorg-video-intel:
status: Confirmed → Incomplete
Papamatti (matti-lx) wrote :

Stil happens in Ubuntu 12.10.

It's not fixed in Ubuntu 12.10 (I've just tested):
xserver-xorg-video-intel 2:2.20.9-0ubuntu2
linux-image-3.5.0-17

but in a downstream bug ( https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/745608/comments/155 ) people mention that using SNA resolves the issue.

Jesse:
What change were you thinking might have fixed this issue?

I didn't have a specific change in mind, I guess SNA doesn't work for you though?

SNA does work for me (I just hadn't tested it on the previous run).

To be honest, I had hoped that this would have proven to be the unfenced-BLT bug. The known w/a for UXA is to enable DebugWait, which implies that UXA is not handling its domains correctly.

The most likely candidate is:

diff --git a/src/intel_uxa.c b/src/intel_uxa.c
index 76a3146..40e3b67 100644
--- a/src/intel_uxa.c
+++ b/src/intel_uxa.c
@@ -1379,8 +1379,8 @@ Bool intel_uxa_init(ScreenPtr screen)
        }

        /* PutImage */
- intel->uxa_driver->put_image = intel_uxa_put_image;
- intel->uxa_driver->get_image = intel_uxa_get_image;
+ //intel->uxa_driver->put_image = intel_uxa_put_image;
+ //intel->uxa_driver->get_image = intel_uxa_get_image;

        intel->uxa_driver->prepare_access = intel_uxa_prepare_access;
        intel->uxa_driver->finish_access = intel_uxa_finish_access;

Changed in xserver-xorg-video-intel:
status: Incomplete → Confirmed

I've pushed a tree to remove some of the optimisations to see if they are the cause of the corruption:

http://cgit.freedesktop.org/~ickle/xf86-video-intel #glyph-cache-bug

Can you please try this branch to see if does the trick?

Rough guide to testing:

$ git clone git://people.freedesktop.org/~ickle/xf86-video-intel
$ cd xf86-video-intel
$ git checkout origin/glyph-cache-bug
$ ./autogen.sh --prefix=/usr
$ make
$ sudo make install
# restart X

Chris:
I'm going to struggle to even test your simple patch. How easy is it to cross compile this on a 64 bit Fedora for a 32 bit Ubuntu with a different xorg?

Nigh-on impossible unless you have the entire build environment for your target as well (-intel will depend upon the X server ABI as defined in the headers, which of course vary over time).

Don't worry the fix is just to switch to SNA, which will happen soon enough.

Andris Berzins (pkix) wrote :

I have the same issue running DELL Latitude D430 with Intel Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller.

I can confirm, that SNA workaround fixes the issue.

$ cat /etc/X11/xorg.conf
Section "Device"
 Identifier "Card0"
 Driver "intel"
 Option "AccelMethod" "sna"
EndSection

Ok I've built the intel driver on the git branch (the log mentioned it was version 2.20.16) mentioned and the problem is still there.

Created attachment 71918
Flush around glyph updates

Created attachment 71919
Flush around glyph updates

Rushed.

Created attachment 71944
Disable glyph cache

Created attachment 71949
Screenshot of patched driver with filled in glyphs

If you look at this screenshot which is using the patch on http://paste.debian.net/218151/ you will see that some blocks have lines through them

Created attachment 71953
Screenshot 2 of patched driver with filled in glyphs

This was taken using the patch on http://paste.debian.net/218164/ but no errors were logged...

Sitosfe, if you get a chance, please could you try -intel.git (or 2.20.18)? I've implemented stricter throttling, so I am wondering if that worksaround the issue like DebugWait.

Sitsofe reports that commit 441ef916ae6569c88b3d6abaf7fea4d69be49d76
Author: Chris Wilson <email address hidden>
Date: Thu Jan 10 19:14:21 2013 +0000

    intel: Throttle harder

does improve matters, but I'm still at a loss to explain why.

*** Bug 37782 has been marked as a duplicate of this bug. ***

*** Bug 49396 has been marked as a duplicate of this bug. ***

*** Bug 39851 has been marked as a duplicate of this bug. ***

*** Bug 55881 has been marked as a duplicate of this bug. ***

(In reply to comment #76)
> Sitsofe reports that commit 441ef916ae6569c88b3d6abaf7fea4d69be49d76
> Author: Chris Wilson <email address hidden>
> Date: Thu Jan 10 19:14:21 2013 +0000
>
> intel: Throttle harder
>
> does improve matters, but I'm still at a loss to explain why.

Finally I got some time to test that patch too. I checked out branch `debian-unstable` from the Debian packaging Git repository [1] (based on release 2.19.0)

    commit 8ab872522ae0891b8fb52fbb31db52d581c3efa3
    Author: Julien Cristau <email address hidden>
    Date: Sun Sep 16 20:47:05 2012 +0200

        Upload to unstable

and applied the following patch on top of it.

    commit f49c3cacd25ffb78ccfff49b001ba89375044145
    Author: Chris Wilson <email address hidden>
    Date: Thu Jan 10 19:14:21 2013 +0000

        intel: Throttle harder

Limited testing shows that the glyph corruption is gone. Unfortunately performance seems to be slower too. That means for example maximizing a window it does not happen instantly and I can see how it is redrawn. So basically the same behavior with `"DebugWait" "true"`, if I remember correctly.

[1] http://anonscm.debian.org/gitweb/?p=pkg-xorg/driver/xserver-xorg-video-intel.git;a=summary

(In reply to comment #81)
> and applied the following patch on top of it.
>
> commit f49c3cacd25ffb78ccfff49b001ba89375044145
> Author: Chris Wilson <email address hidden>
> Date: Thu Jan 10 19:14:21 2013 +0000
>
> intel: Throttle harder
>
> Limited testing shows that the glyph corruption is gone. Unfortunately
> performance seems to be slower too. That means for example maximizing a
> window it does not happen instantly and I can see how it is redrawn. So
> basically the same behavior with `"DebugWait" "true"`, if I remember
> correctly.

What I realised later was that Sitosfe was hitting the bug in libdrm-intel that was causing it to fallback to swrast. After applying that patch, you also need libdrm-intel-2.4.41 or just http://cgit.freedesktop.org/mesa/drm/commit/?id=fdda97007b1dbf95beb16a0e3510fd36c89e8c33

Paul, can you update libdrm and see if the bug returns?

(In reply to comment #82)
> (In reply to comment #81)
> > and applied the following patch on top of it.
> >
> > commit f49c3cacd25ffb78ccfff49b001ba89375044145
> > Author: Chris Wilson <email address hidden>
> > Date: Thu Jan 10 19:14:21 2013 +0000
> >
> > intel: Throttle harder
> >
> > Limited testing shows that the glyph corruption is gone. Unfortunately
> > performance seems to be slower too. That means for example maximizing a
> > window it does not happen instantly and I can see how it is redrawn. So
> > basically the same behavior with `"DebugWait" "true"`, if I remember
> > correctly.
>
> What I realised later was that Sitosfe was hitting the bug in libdrm-intel
> that was causing it to fallback to swrast. After applying that patch, you
> also need libdrm-intel-2.4.41 or just
> http://cgit.freedesktop.org/mesa/drm/commit/
> ?id=fdda97007b1dbf95beb16a0e3510fd36c89e8c33
>
> Paul, can you update libdrm and see if the bug returns?

I applied the commit you mentioned on top of

    libdrm (2.4.40-1~deb7u2) sid; urgency=low

and rebuilt the package. Unfortunately I think there is no difference. The glyph corruption is still gone but it is also still slow, so swrast still might be used.

How can I check, what is used, without `glxinfo` installed? I could not spot anything useful in `/var/log/Xorg.0.log`.

Basically inspect 'sudo perf top' for pixman functions. There is a slim chance you trigger bug 59711 (as in I have no idea what that is about...) and end up with something in the Xorg.log.

Download full text (12.0 KiB)

(In reply to comment #83)
> (In reply to comment #82)
> > (In reply to comment #81)

[…]

> > Paul, can you update libdrm and see if the bug returns?
>
> I applied the commit you mentioned on top of
>
> libdrm (2.4.40-1~deb7u2) sid; urgency=low
>
> and rebuilt the package. Unfortunately I think there is no difference. The
> glyph corruption is still gone but it is also still slow, so swrast still
> might be used.
>
> How can I check, what is used, without `glxinfo` installed? I could not spot
> anything useful in `/var/log/Xorg.0.log`.

It looks like swrast is not used.

    OpenGL renderer string: Mesa DRI Intel(R) 915GM x86/MMX/SSE2
    OpenGL version string: 1.4 Mesa 8.0.5

Here is the full output.

$ glxinfo
name of display: :0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
    GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample,
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group,
    GLX_INTEL_swap_event
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile,
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_framebuffer_sRGB,
    GLX_EXT_create_context_es2_profile, GLX_MESA_copy_sub_buffer,
    GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control,
    GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read,
    GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample,
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group,
    GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event
GLX version: 1.4
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
    GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control,
    GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read,
    GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample,
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group,
    GLX_EXT_texture_from_pixmap
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 915GM x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 8.0.5
OpenGL extensions:
    GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
    GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture,
    GL_EXT_polygon_offset, GL_EXT_subtexture, GL_EXT_texture_object,
    GL_EXT_vertex_array, GL_EXT_compiled_vertex_array, GL_EXT_texture,
    GL_EXT_texture3D, GL_IBM_rasterpos_clip, GL_ARB_point_parameters,
    GL_EXT_draw_range_elements, GL_EXT_packed_pixels, GL_EXT_point_parameters,
    GL_EXT_rescale_normal, GL_EXT_separate_specular_color,
    GL_EXT_texture_edge_clamp, GL_SGIS_generate_mipmap,
    GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp,
    GL_SGIS_textu...

(In reply to comment #84)
> Basically inspect 'sudo perf top' for pixman functions.

Alright.

> There is a slim chance you trigger bug 59711 (as in I have no idea what that
> is about...) and end up with something in the Xorg.log.

Unfortunately with two patches applied, using `xrandr` to enable the external screen seems to lock up the system. I have to find more time to look into this.

Chris Wilson (ickle) wrote :

Not an issue for raring (due to it using SNA).

Changed in xserver-xorg-video-intel (Ubuntu):
status: Triaged → Fix Released

*** Bug 65433 has been marked as a duplicate of this bug. ***

I have removed xorg-x11-drv-intel thinking it would fall back to xorg-x11-drv-vesa but it seems to have fallen back to i915 from the kernel. Is this correct?

Anyway, the font corruption issue disappeared.

What is the difference between using the driver from xorg-x11-drv-intel and the one from the kernel?

(In reply to comment #88)
> I have removed xorg-x11-drv-intel thinking it would fall back to
> xorg-x11-drv-vesa but it seems to have fallen back to i915 from the kernel.
> Is this correct?

No. I guess you are using xorg-x11-drv-modesetting as that is the modern fallback.

> Anyway, the font corruption issue disappeared.

The right fix is to enable Option "AccelMethod" "SNA".

thinkpad (fellowsgarden) wrote :

"Years ago" I applied the solution described here http://askubuntu.com/a/49941/16023

I'm still on "precise" (not "raring").

Lately, the issue's been cropping up more often again.

What's the latest consensus on how to resolve this issue in "precise" ?

Anything else worth trying?

Diego (gran-diego) wrote :

Had this same issue. Workaround in #167 works for me.

Ubuntu Raring on Dell Latitude E4300. Intel GM45 video card (i915 module)

Created attachment 93730
Screenshot 1 of 5, terminal filled with X's, corruption changes after scrot

Created attachment 93731
Screenshot 1 of 5, terminal filled with X's, corruption changes after scrot

Created attachment 93732
Screenshot 2 of 5, terminal filled with X's, corruption changes after scrot

Created attachment 93733
Screenshot 3 of 5, terminal filled with X's, corruption changes after scrot

Created attachment 93734
Screenshot 4 of 5, terminal filled with X's, corruption changes after scrot

Created attachment 93735
Screenshot 5 of 5, terminal filled with X's, corruption changes after scrot

Created attachment 93736
Log files dmesg + Xorg,0,log showing machine info for screenshots above

Screenshots and logs for <email address hidden> are on a system running
Kernel 3.11.0-12-generic #19-Ubuntu
xorg-intel 2:2.99.904-0ubuntu2
SNA is on: intel(0): SNA initialized with Eaglelake (gen4.5) backend
Chipset is a Q45/Q43.

linux.testing.marantz:
I've add you to the CC list of this bug report so you will see a reply. It is a good practice to do this otherwise you will miss followups...

It is unlikely that the bug you are seeing is the one filed here as your chipset is not an i915 series and you are using SNA on a recent kernel+xorg. I would strongly urge you to open new bug, attach one of your screenshots, your xorg and dmesg logs and then report the versions of your kernel, xorg and xorg intel along with steps on how to reproduce the issue in a comment.

I don't see this in Ubuntu 14.04 as it uses SNA and UXA is going to die so I think we can finally close this.

Changed in xserver-xorg-video-intel:
status: Confirmed → Fix Released

I ran into this bug on a fresh install of Debian 8 (Jessie) RC2 on an EeePC 701 4G with Intel i915GM graphics. Linux kernel 3.16, X.Org 1.16.4, X.Org intel module 2.21.15.

Using SNA instead of UXA, as suggested above, seems to still solve it:

# cat /etc/X11/xorg.conf
Section "Device"
        Identifier "Intel Graphics"
        Driver "intel"
        Option "AccelMethod" "sna"
EndSection

I see that Debian is preparing to move to SNA [1]:

> xserver-xorg-video-intel (2:2.99.911+git20140529-1~exp2) experimental; urgency=medium
> ..
> * Stop overriding default upstream acceleration method (i.e. default to SNA
> instead of UXA).
>
> -- Vincent Cheng <email address hidden> Mon, 02 Jun 2014 23:47:23 -0700

However, that change is still in Debian's "experimental" area, not in the upcoming stable (Jessie) release.

(Links to corresponding Debian bug reports in Paul's comment 44 above.)

[1] http://metadata.ftp-master.debian.org/changelogs//main/x/xserver-xorg-video-intel/experimental_changelog

Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/745608

tags: added: iso-testing
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.