Bug 26002 - [i915GM] occasional font corruption
[i915GM] occasional font corruption
Status: RESOLVED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel)
All Linux
: P1 normal
Assigned To: drivers_video-dri-intel@kernel-bugs.osdl.org
:
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2011-01-01 14:52 UTC by S. Christian Collins
Modified: 2012-05-03 20:44 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.37-rc8
Tree: Mainline
Regression: Yes


Attachments
screenshot of font corruption (34.02 KB, image/png)
2011-01-01 14:52 UTC, S. Christian Collins
Details
Xorg log (27.39 KB, application/octet-stream)
2011-01-03 02:03 UTC, S. Christian Collins
Details
dmesg output (57.40 KB, text/plain)
2011-01-03 02:05 UTC, S. Christian Collins
Details
lshw output (62.33 KB, text/html)
2011-01-03 02:05 UTC, S. Christian Collins
Details
Font corruption on linux 3.4.0-rc3 (260.66 KB, image/png)
2012-04-22 15:43 UTC, Eddy Petrișor
Details
string.printable output (19.18 KB, image/png)
2012-04-22 18:51 UTC, Eddy Petrișor
Details
intel-gpu-tools make test output (53.11 KB, text/plain)
2012-04-23 21:53 UTC, Eddy Petrișor
Details

Description S. Christian Collins 2011-01-01 14:52:00 UTC
Created attachment 42092 [details]
screenshot of font corruption

Occasionally, fonts within an application will appear with pieces missing from one or more glyphs (see attached screenshot).  This seems to happen most commonly with OpenOffice.org, second-most with Firefox from the different applications I have tried.  The problem also seems much more likely to occur after resuming from suspend.

The following link also seems to be related to this issue:
https://bbs.archlinux.org/viewtopic.php?id=103757

There is a mention of the font rendering issues in this post:
http://ubuntuforums.org/showpost.php?p=9187302&postcount=4
Comment 1 Chris Wilson 2011-01-02 09:27:50 UTC
Are you not going to mention a few pertinent details, such as chipset, a dmesg, Xorg.log or driver versions, but just link to circumstantial evidence?
Comment 2 S. Christian Collins 2011-01-03 02:03:36 UTC
Created attachment 42142 [details]
Xorg log

I'm sorry, this wasn't a very good bug report was it?  I have attached my Xorg log, dmesg output and lshw output.  I'm not sure what the official chipset is, but I'm sure the graphics are "Mobile 915GM".

I have reproduced this bug using the following kernels: 2.6.35 (Ubuntu Maverick generic kernel) and 2.6.37-rc8.
I have reproduced this bug using the following xserver-xorg-video-intel driver versions: 2.12.0 (current Ubuntu Maverick version) and 2.13.901 (from ppa:ubuntu-x-swat/x-updates).

Please let me know if you need any more information.
Comment 3 S. Christian Collins 2011-01-03 02:05:02 UTC
Created attachment 42152 [details]
dmesg output
Comment 4 S. Christian Collins 2011-01-03 02:05:54 UTC
Created attachment 42162 [details]
lshw output
Comment 5 Rafael J. Wysocki 2011-01-03 20:51:32 UTC
Does 2.6.36 work correctly?
Comment 6 Chris Wilson 2011-01-03 20:59:49 UTC
Depends, I've very similar reports from 2.6.33. One of the most important assessments would be whether it is glyph data that existed before the suspend that is corrupted or whether it is glyph data that we attempted to upload afterwards. The later could be explained by a clflush issue that became critical in -next (but I couldn't see any reason why the current kernels did not also suffer from the same bug, just without any valid reason to push the patch to -fixes).
Comment 7 S. Christian Collins 2011-01-14 22:15:24 UTC
To answer your question, Rafael: kernel 2.6.36 has the same problem.
Comment 8 Eddy Petrișor 2011-03-27 00:17:22 UTC
I think I have experienced the same problem, but it is not limited to 2.6.36, the problem is visible in 2.6.32, too. I have reported this bug in the Debian BTS here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613317


There are screenshots, dmesg and xorg logs there.

dmesg: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=44;filename=dmesg.txt;att=1;bug=613317

xorg.log: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=44;filename=Xorg.0.log;att=2;bug=613317


The graphics card is also an Intel card and there are also background image corruptions which manifest on vanilla 2.6.37+git35d34df7.
Comment 9 Eddy Petrișor 2011-04-09 21:11:22 UTC
I have just observed that gitk's fonts and xterm's fixed fonts were not affected. I hope this info is useful.
Comment 10 Eddy Petrișor 2011-04-15 08:37:01 UTC
Is this the same bug as bug #27572?
Comment 11 S. Christian Collins 2011-04-15 14:11:54 UTC
Bug #27572 seems to be related to a different type of corruption.  The bug reported here only mentions corrupted font glyphs.  However, there may be a similar cause to both this bug and #27572--some kind of memory corruption?
Comment 12 S. Christian Collins 2011-05-04 17:55:06 UTC
This bug is still present in Ubuntu Natty (running Xubuntu 32-bit).
Kernel: 2.6.38-8-generic
Intel driver: 2:2.14.0-4ubuntu7.1

** 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
Comment 13 Ferry Toth 2011-05-18 15:21:09 UTC
See https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/745608

See screenshots at #16 - #19 taken on the 945G

I have 3 different machines (different intel video chipset), one of which suffers badly from this bug.

Summery:

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 (kernel 2.38-8.42), 915GM and 82G33 in i386, 82945G in amd64.

Ferry
Comment 14 Ferry Toth 2011-05-21 22:15:53 UTC
Sitsofe Wheeler gave me the advise to try putting the following in my xorg.conf:

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

As there was no xorg.conf I created one with only the lines above (rest auto detected).

The font corruption is now disappeared.

I have no clue why and if we should now close this bug.

But this seems to be a good workaround.

Ferry
Comment 15 Daniel Vetter 2012-04-12 15:44:47 UTC
Ok, 3.4-rc2 has fixes for all known tiling issues and regressions (which this one is likely yet another case of) for gen3 (i.e. i915, i945, g33, pnv). Please test with that kernel and check whether you're still seeing these corruptions.
Comment 16 Daniel Vetter 2012-04-12 15:47:24 UTC
More precisely

commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Mar 21 10:48:18 2012 +0000

    drm/i915: Mark untiled BLT commands as fenced on gen2/3

and

commit c9c4b6f6c28354f1df9bd288dc33ba7ae0e66aaa
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Dec 14 13:57:15 2011 +0100

    drm/i915: fix swizzle detection for gen3

I'll close this issue as fixed, please reopen if you still see corruptions on kernels with these 2 patches applied.
Comment 17 Eddy Petrișor 2012-04-20 07:30:17 UTC
(In reply to comment #16)
> More precisely
> 
> commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Wed Mar 21 10:48:18 2012 +0000
> 
>     drm/i915: Mark untiled BLT commands as fenced on gen2/3
> 
> and
> 
> commit c9c4b6f6c28354f1df9bd288dc33ba7ae0e66aaa
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Wed Dec 14 13:57:15 2011 +0100
> 
>     drm/i915: fix swizzle detection for gen3
> 
> I'll close this issue as fixed, please reopen if you still see corruptions on
> kernels with these 2 patches applied.

I'll compile and try this. I am running Debian's 3.2.0 kernel and still experience this kind of corruption after some hibernate/resume cycles.

Meanwhile I realised gitk and xterm were not affected because they used other fonts than the rest of the applications and only the fonts used at the time of the hibernate were the ones affected.

I'll come back (probably Sunday) for feedback.
Comment 18 Eddy Petrișor 2012-04-22 15:41:01 UTC
(In reply to comment #16)
> More precisely
> 
> commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Wed Mar 21 10:48:18 2012 +0000
> 
>     drm/i915: Mark untiled BLT commands as fenced on gen2/3
> 
> and
> 
> commit c9c4b6f6c28354f1df9bd288dc33ba7ae0e66aaa
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Wed Dec 14 13:57:15 2011 +0100
> 
>     drm/i915: fix swizzle detection for gen3
> 
> I'll close this issue as fixed, please reopen if you still see corruptions on
> kernels with these 2 patches applied.

Unfortunately the bug it still present on my system.
Comment 19 Eddy Petrișor 2012-04-22 15:43:07 UTC
Created attachment 73032 [details]
Font corruption on linux 3.4.0-rc3

As you can see, I still got font corruption after a hibernate-sleep cycle with linux 3.4.0-rc3.
Comment 20 Eddy Petrișor 2012-04-22 15:45:15 UTC
I am unable to reopen the bug since, it seems, I don't have the necessary rights. So, please, somebody with the necessary rights, reopen the bug.
Comment 21 Chris Wilson 2012-04-22 16:02:10 UTC
How similar is this to https://bugs.freedesktop.org/show_bug.cgi?id=36326 ?
Comment 22 Daniel Vetter 2012-04-22 18:05:47 UTC
Ok, we need to run a few tests: Can you please grab the intel-gpu-tools suite from git git://anongit.freedesktop.org/xorg/app/intel-gpu-tools and run the kernel test-suite with

# make test

You need to be root and no other drm client like X may be running. Please attach the output of the complete test-run (and yes, it takes a while).
Comment 23 Eddy Petrișor 2012-04-22 18:50:53 UTC
(In reply to comment #21)
> How similar is this to https://bugs.freedesktop.org/show_bug.cgi?id=36326 ?

I am sorry in advance if I didn't understood the proper meaning of your question, but it doesn't look similar to that. It seems that the bug 36326 manifests as certain glyph line deletion, while in my case loos like glyph scrambling. Please be more specific, if I didn't understand what your line of questioning.

I guess the intel-gpu-tools suite will bring up more info.
Comment 24 Eddy Petrișor 2012-04-22 18:51:52 UTC
Created attachment 73046 [details]
string.printable output

Here is a string.printable output on my machine.
Comment 25 Chris Wilson 2012-04-22 19:32:35 UTC
(In reply to comment #23)
> (In reply to comment #21)
> > How similar is this to https://bugs.freedesktop.org/show_bug.cgi?id=36326 ?
> 
> I am sorry in advance if I didn't understood the proper meaning of your
> question, but it doesn't look similar to that. It seems that the bug 36326
> manifests as certain glyph line deletion, while in my case loos like glyph
> scrambling.

That's precisely what I was trying to verify, thank you. From your description of this being swap triggered (or hibernate) in this case it is likely to be swizzling at fault. If you had seen a pattern like 36326, that would just be corruption whilst uploading or somesuch (and so likely to have been another bug like drm/i915: Mark untiled BLT commands as fenced on gen2/3).
Comment 26 Daniel Vetter 2012-04-22 19:35:04 UTC
Meh, I've just noticed that Eddy has a i965GM whereas the original reporter has a i915GM. The i965GM issue likely L-shaped bit17 swizzling woes, and should be easily detectable by tiled_swapping failing in i-g-t.

The i915gm issues should be solve, Christian, please reopen if this is not the case.

Eddy, please attach the output of the intel-gpu-tools testsuite so I can tell you whether this is a known issue.

Everyone else: If you still have issues with v3.4-rc series, please open new bug reports - if you have corruptions but not exactly matching hw there's a really big chance that you have a different bug.
Comment 27 Eddy Petrișor 2012-04-23 21:53:10 UTC
Created attachment 73056 [details]
intel-gpu-tools make test output

Here is the output of 'make test' on 3.4.0-rc3.

Interestingly enough 'make test' on the Debian 3.2.0 kernel lead to lots of failed tests, a kernel oops and, obviosly failed to finish, while 3.4.0-rc3 looks a lot more stable, although there were some failures.

BTW, pointing out the configuration options that enabled the right debugfs interface would have been useful, it took me 4 kernel recompilations and some manual tinkering of the .config after seeing the official Debian kernel 3.2.0 has the proper dri interface on debugfs.
Comment 28 Eddy Petrișor 2012-04-27 07:13:55 UTC
(In reply to comment #26)
> Meh, I've just noticed that Eddy has a i965GM whereas the original reporter has
> a i915GM. The i965GM issue likely L-shaped bit17 swizzling woes, and should be
> easily detectable by tiled_swapping failing in i-g-t.
> 
> The i915gm issues should be solve, Christian, please reopen if this is not the
> case.
> 
> Eddy, please attach the output of the intel-gpu-tools testsuite so I can tell
> you whether this is a known issue.
> 
> Everyone else: If you still have issues with v3.4-rc series, please open new
> bug reports - if you have corruptions but not exactly matching hw there's a
> really big chance that you have a different bug.

Any news? I already posted the output of make test a few days ago and it looks to me like you were right on your suspicion. Is so, what's next?
Comment 29 S. Christian Collins 2012-05-03 16:54:59 UTC
I am still experiencing this bug on Kubuntu Precise and am reopening the bug per comment #26.  I am using xserver-xorg-video-intel version 2:2.19.0-0ubuntu1~xup1 from the X Updates PPA (https://launchpad.net/~ubuntu-x-swat/+archive/x-updates) and can still reproduce the glyph corruption using the following i386 kernels:
 . 3.4.0-030400rc5-generic from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc5-precise/
 . 3.4.0-994-generic from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-experimental/2012-05-03-precise/

Anything else I should try?  Xorg-edgers perhaps?

** Current System Info **
OS: Kubuntu 12.04 i386 w/ KDE SC 4.8.2
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
Linux Kernel: 3.2.0-24-generic
Screen Resolution: 1280 x 768
Comment 30 S. Christian Collins 2012-05-03 17:48:31 UTC
Okay, so I bit the bullet and updated X and the intel driver using the following PPAs:
 . xorg-edgers (https://launchpad.net/~xorg-edgers/+archive/ppa)
 . intel-sna branch (https://launchpad.net/~sarvatt/+archive/intel-sna)

I also used the 3.4.0-030400rc5-generic kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc5-precise/

I'm not sure if the intel-sna branch or kernel update was necessary, but I have not been able to reproduce this bug since updating.  The updated X + driver did cause other issues for me, though, particularly with OpenGL apps, just as a warning to anyone else wishing to try this driver.  Closing again as fixed.
Comment 31 Chris Wilson 2012-05-03 17:56:49 UTC
(In reply to comment #30)
> The updated X + driver did
> cause other issues for me, though, particularly with OpenGL apps, just as a
> warning to anyone else wishing to try this driver.

A warning is not much help for me to fix them... Can you please file a bug on bugzilla.freedesktop.org and attach your Xorg.0.log?
Comment 32 S. Christian Collins 2012-05-03 19:03:31 UTC
Here you go :)
https://bugs.freedesktop.org/show_bug.cgi?id=49442
Comment 33 S. Christian Collins 2012-05-03 20:44:40 UTC
While testing for other bugs, I discovered that this driver exhibits the font corruption bug:
2:2.19.0+git20120501.7e09babb-0ubuntu0sarvatt~precise (from xorg-edgers PPA)
...and this one doesn't:
2:2.19.0+git20120501.7e09babb-0ubuntu0sarvatt2~sna~precise (from intel-sna PPA)

Same version, but the second driver uses SNA (Sandy Bridge New Acceleration).  Is SNA going to eventually become the default acceleration in the Intel driver?  Will this be enabled on all i915GM hardware?  If not, then should this bug be reopened?

Note You need to log in before you can comment on or make changes to this bug.