Bug 496910 - X non-functional after resume from suspend (ThinkPad R51)
X non-functional after resume from suspend (ThinkPad R51)
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-i810 (Show other bugs)
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2009-04-21 11:52 EDT by Ian Collier
Modified: 2009-12-04 12:58 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-12-04 12:58:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Output of lspci -nn (2.18 KB, text/plain)
2009-04-21 11:52 EDT, Ian Collier
no flags Details
xorg.conf (668 bytes, text/plain)
2009-04-21 11:54 EDT, Ian Collier
no flags Details
Xorg.0.log (63.50 KB, text/plain)
2009-04-21 11:59 EDT, Ian Collier
no flags Details

  None (edit)
Description Ian Collier 2009-04-21 11:52:53 EDT
Created attachment 340560 [details]
Output of lspci -nn

Description of problem:
After typing pm-suspend or pressing the suspend button in gnome-power-manager or closing the lid (if enabled), when the system is woken up everything is more or less functional apart from X.  I can see the ghosts of my windows but contents are barely visible.  The precise visual effect depends on whether EXA or XAA acceleration is used.  In the former case the X background and terminal windows are drawn but they have no frames; they don't update properly when text is typed, and they don't disappear when iconised.  Some other windows are rendered as just an area of background colour with no contents (this includes the gdm login screen, which appears as just some coloured rectangles although oddly the background image is present).  With XAA the terminal windows are completely black and do not have text in them.

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

How reproducible:
Usually.  I thought I had fixed it by setting QUIRK_VBE_POST in a config file and did several successful suspend/resume cycles, but that must have been a coincidence because several days later, without an intervening reboot, it failed again and no amount of reboots or cold starts would make it work.  Also tried all the quirks in various combinations.  It has worked OK once, but only once, since then.

Steps to Reproduce:
1. pm-suspend
2. wake the machine up
3. voila
Actual results:
improperly drawn windows and generally garbled screen

Expected results:
working windows that look like they did just before the suspend

Additional info:
This is not using kernel modsetting (actually, this version of X doesn't seem to work with kernel modestting).

I am not using anything that uses the Composite extension, as far as I am aware (in fact my window manager is fvwm).  It *might* relate to having run something that uses OpenGL, but again it happens when I've not knowingly run any OpenGL applications since booting up.

I had exactly the same problem in Fedora Core 6, which I solved by adding VBERestore to the i810 driver options [this was the second of two problems, the first of which was implementing a version of the pci-save quirk].  After that it worked pretty much flawlessly.  The Fedora 10 intel driver doesn't accept this option, however, so that fix no longer works.

Since you can still type into the terminal windows (it just may not display what you type) it's possible to execute pm-hibernate.  This restores everything to working order (except the first couple of times when the kernel panicked early during the thaw process).
Comment 1 Ian Collier 2009-04-21 11:54:32 EDT
Created attachment 340561 [details]

This happens with or without an xorg.conf file, but here's the conf I am currently using.
Comment 2 Ian Collier 2009-04-21 11:59:03 EDT
Created attachment 340564 [details]

This is the current Xorg.0.log with the above xorg.conf.  During this session I have run pm-suspend once (X came back non-functional) followed by pm-suspend once (X restored to working order).  X does not seem to output any useful messages during this process.

Also I might note that terminating X and restarting it doesn't cure the condition; only a full hibernate or reboot does.
Comment 3 jcline 2009-08-12 20:04:44 EDT
I have the same bug on a Thinkpad X40, running Debian.  It appeared when I upgraded Debian distributions, and was forced to switch from XF86 to xorg.
The problem did not occur with XF86, so it seems to be a bug with xorg.  My
xorg is Release 7.1.1 and it is using the i810 driver.  I also find the problem occurs with or without having an xorg.conf file present.
Comment 4 Vedran Miletić 2009-11-05 18:12:30 EST
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, including Intel driver, which may have resolved this issue.
To be more precise, Intel has undergone a major rewrite during Fedora 10, 11 and 12 cycles, and whole driver is working a lot better now. Users who have experienced this problem are encouraged to retry with at least Fedora 12 Beta and see if the issue is still relevant.

Please, if you experience this problem on Fedora 12 Beta or up-to-date system running Rawhide, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

We hope to see how many older bugs in Intel driver are still relevant today, in hope that most of them were fixed in rewrite process.

[This is a bulk message for all open Fedora 10 i810-related bugs (39 of them are still open). I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Comment 5 Bug Zapper 2009-11-18 06:49:35 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  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 '10'.

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 10'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 10 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
Comment 6 Ian Collier 2009-11-18 07:07:40 EST
Right at the moment on F12 it's a bit difficult to test this because the machine locks hard on the way down (suspend LED still blinking, backlight still on). :-/
Comment 7 Vedran Miletić 2009-12-04 12:58:03 EST
Thank you for your bug report.

We are sorry, but the Fedora Project is will soon stop longer releasing bug fixes or any other updates for this version of Fedora. There were so many changes between Fedora 10 and Fedora 12 in Intel driver and X.Org that it's very likely that this bug is fixed. This bug will be set to CLOSED:WONTFIX to reflect this, but please reopen it if the problem persists after upgrading to the latest version of Fedora (version 12), which is available from:


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