Bug 859653 - Greatly-worsened graphical corruption with intel 2.20.7
Greatly-worsened graphical corruption with intel 2.20.7
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-09-22 15:34 EDT by "FeRD" (Frank Dana)
Modified: 2013-07-31 13:52 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-07-31 13:52:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Screenshot, showing text garbling in left-hand gedit window (559.42 KB, image/png)
2012-09-22 15:34 EDT, "FeRD" (Frank Dana)
no flags Details
Screenshot showing re-occurrence of corruption under libdrm test build (817.71 KB, image/png)
2012-09-26 14:08 EDT, "FeRD" (Frank Dana)
no flags Details

  None (edit)
Description "FeRD" (Frank Dana) 2012-09-22 15:34:45 EDT
Created attachment 615903 [details]
Screenshot, showing text garbling in left-hand gedit window

Description of problem:
Like some other intel GPU users, for some time I've been seeing graphical corruption when using my laptop's HDMI output to an external display (see #851280, #848099, others), but it was mostly confined to window decorations, and fairly limited/tolerable.

Since the update to xorg-x11-drv-intel-2.20.7 this morning, I'm seeing massive and frequent text garbling (a slightly different symptom than before, and much more aggressive), making it extremely difficult to use the system.

Version-Release number of selected component (if applicable):

How reproducible:
The problem manifests shortly after login (trigger unknown), and then occurs randomly and unpredictably, but very frequently. Changing window focus, scrolling, or simply clicking in a window can all cause the contents to be partly-scrambled. (See attached screenshot, specifically the lower parts of the gedit window on the left.)

Additional info:

% sudo lspci -v -nn -s 00:02.1
00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07)
	Subsystem: Lenovo Device [17aa:3a02]
	Flags: bus master, fast devsel, latency 0
	Memory at f4400000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: [d0] Power Management version 3

I am seeing some of this in dmesg output, although the symptoms seem to start even before this message appears:

[ 6235.789812] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
[ 6235.790049] i915: render error detected, EIR: 0x00000010
[ 6235.790049] i915:   IPEIR: 0x00000000
[ 6235.790049] i915:   IPEHR: 0x00000000
[ 6235.790049] i915:   INSTDONE: 0xfffffffe
[ 6235.790049] i915:   INSTPS: 0x0001e000
[ 6235.790049] i915:   INSTDONE1: 0xffffffff
[ 6235.790049] i915:   ACTHD: 0x2a00eed8
[ 6235.790049] i915: page table error
[ 6235.790049] i915:   PGTBL_ER: 0x00000001
[ 6235.790049] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
Comment 1 Adam Jackson 2012-09-24 11:01:54 EDT
What driver version were you running before?  (yum history has answers.)  Does downgrading to that driver restore the old behaviour, or is it actually a kernel change you're seeing?
Comment 2 Jes Sorensen 2012-09-25 05:14:16 EDT
I see the same problem, I am not 100% sure which version works for me.

In my case, I believe the problems started on September 5th when I installed
this one:
Sep 05 10:34:08 Updated: xorg-x11-drv-intel-2.20.5-1.fc17.x86_64

Since then I have tried the .6 and .7 releases, both which don't work. I am
now testing .4 to see if it is better - unfortunately it can take quite a while
for the problems to show up.

Will report back.

Comment 3 "FeRD" (Frank Dana) 2012-09-25 09:20:42 EDT
*sigh* Well, now I'm even less certain where the issue lies, because I'm no longer able to reproduce the acute text-corruption I reported. That's somehow cleared up on its own, and my system has dropped back to just the same low-level interface corruption (window decorations, tooltips, sometimes overview mode) that I've been seeing for weeks now.

However, to Adam's question about versions, it does appear that my system received both new kernel and driver versions in the same update run, shortly before I made this report... so, I can't say for certain that one or the other was the problem.

The before/after on those versions, tho, for the record, is:

Before (Since 2012-09-07)

After (On 2012-09-22, a few hours before I opened this bug)

Since my system at present is exhibiting the same behavior I've been seeing all along — I only started using the HDMI output on this laptop again a month or so ago, and have been seeing corruption all along — don't think that shuffling around to older versions now would be of any use, unfortunately.)
Comment 4 Adam Jackson 2012-09-25 12:21:26 EDT
Well, there aren't any i915 or generic drm changes between 3.5.3 and 3.5.4 that would apply here.

The big change to the X driver between those points was adding prime support, and there does appear to be a fix for prime buffers in newer libdrm.  Try this test build:

Comment 5 Adam Jackson 2012-09-25 14:19:25 EDT
Ugh.  That won't actually install on an F17 machine unless you force things, lousy nouveau ABI changing all the time.  New one coming shortly.
Comment 6 Adam Jackson 2012-09-25 14:23:54 EDT
Sorry, was looking at an F18 machine, should work on F17.  Go ahead and --nodeps it in if you're not needing nouveau to work, you can yum distro-sync to the released versions afterwards.
Comment 7 "FeRD" (Frank Dana) 2012-09-25 15:50:52 EDT
Thanks, Adam... I've instaled on my laptop, without dependency incident:

          x86_64 2.4.39-1.fc17.jx1 /drm-utils-2.4.39-1.fc17.jx1.x86_64    161 k
 libdrm   i686   2.4.39-1.fc17.jx1 /libdrm-2.4.39-1.fc17.jx1.i686         280 k
 libdrm   x86_64 2.4.39-1.fc17.jx1 /libdrm-2.4.39-1.fc17.jx1.x86_64       281 k
          x86_64 2.4.39-1.fc17.jx1 /libdrm-devel-2.4.39-1.fc17.jx1.x86_64 285 k

...Will kick the tires a little and report back.

Oh, for the record, that upgrade was from the following rev:

Sep 09 08:29:20 Updated: libdrm-2.4.37-1.fc17.x86_64
Sep 09 08:29:22 Updated: libdrm-devel-2.4.37-1.fc17.x86_64
Sep 09 08:29:44 Updated: libdrm-2.4.37-1.fc17.i686
Comment 8 "FeRD" (Frank Dana) 2012-09-26 14:08:48 EDT
Created attachment 617706 [details]
Screenshot showing re-occurrence of corruption under libdrm test build

After fully rebooting my laptop and running with the libdrm-2.4.39-1.fc17.jx1 test build for nearly 24 hours, I was beginning to feel like the situation might be improved; I was still seeing some transient image/icon corruption, but experienced no recurrence of the gnome-shell/mutter window decoration "noise" — that, at least, was a welcome improvement.

Then, a few minutes ago, "something" occurred (I know not what) which re-triggered the massive text corruption problem. It's actually worse than the previous example — in many windows, nearly every text glyph is scrambled; in the case of Firefox and Nautilus, into total unreadability. Screenshot attached.

I can't find anything, anywhere that would seem to indicate the cause of this event, though. Nothing in /var/log/messages, /var/log/Xorg.0.log, or $HOME/.xsession-errors appears to be relevant.

dmesg output is uninteresting. I did find an occurrence, once again, of the i915 render error I included at the end of comment#1... but that message was output more than 18 hours ago, and the most recent message (of any sort) is > 3 hours old.

I'm still running in the corrupted session, in case there's any useful failure information I can capture — I'll try to keep it alive as long as possible, but that may not be very long considering the impact on usability. (For instance, I had to open a Chrome window to post this — all text in Firefox remains unintelligible. Interestingly, the corruption didn't "follow" me into Chrome when it was launched, though some Chrome window titles and etc. are scrambled. So, at least for now, as long as I browse in Chrome I'm unaffected.)

Also, this is probably (past) time I should mention that my system isn't running the standard distro fontconfig and freetype, but rather Infinality's latest patches (http://www.infinality.net/blog/infinality-freetype-patches/) from his Fedora 17 repo:


There's at least a small possibility the font-corruption issue comes from those builds — however, since I'm also seeing image corruption, they can't be solely responsible.
Comment 9 Fedora End Of Life 2013-07-03 15:25:48 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 10 Fedora End Of Life 2013-07-31 13:52:10 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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