Description of problem: Attempts to Resume from hibernation fail. In almost all circumstances, restarting X (via Ctrl-Alt-Backspace) leads to a functioning system, but after all of that delay, and losing all of those X clients Resume is worse than a fresh boot or Restart. Version-Release number of selected component (if applicable): xorg-x11-drv-ati.i386 6.6.3-4.fc7 Similar, if not identical, symptoms are present when running: xorg-x11-drv-ati-6.6.3-2.fc7.i386 except with 6.6.3-2 normal behavior could be triggered by use of power_management.quirk.vbemode_restore (see http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-index.html). How reproducible: Solidly. Has failed every time in tens of attempts. Steps to Reproduce: 1. Solidly. Has failed every time in tens of attempts. 2. After suitable delay, push power button in attempt to Resume. Actual results: After the text mode messages from Resume are displayed, a corrupted purpulish and white screen indicative of a corrupted video buffer is shown for tens of seconds. Sometimes eventually a little black square is rendered for the background of the current cursor position ... although if the cursor is ever rendered, that happens after an even greater delay. Usually by this point in the sequence, the cooling fans have kicked in. If one uses Ctrl+Alt+F1 to switch to a previously opened virtual console running top, after another long delay of up to many tens of seconds, one can glimpse that Xorg was consuming 93% or 97% or ... of the CPU. Within a screen refresh or two of top, Xorg drops to trivial CPU consumption, the cooling fans switch off, and all seems well. Until one uses Alt+F7 to attempt to switch back to the X session, where more unresponsive nothingness is the reward, and the cooling fans turn back on. If the cursor is ever rendered, there is a lag of multiple seconds, frequently many tens of seconds after the cursor is moved before its rendered position on the screen is updated. Sometimes the background area of the password challenge dialog is rendered, and sometimes just the textbox that should appear within this dialog. If one boldly authenticates blind (since the entire dialog is never properly rendered), sometimes the slow-motion chaos begins to paint the edges of the anticipated result, e.g. the background for the top panel and bottom panel of the desktop Usually Ctrl-Alt-Backspace is eventually honored to restart X and allow one to login afresh. Sometimes after this much delay (just before this X session dies), the desktop background may be rendered on any little stripes of it that were peeking around the previously opened windows ... but the area of the client windows themselves remains black. (With one exception. Once, several minutes after the Resume had been initiated, the title bar of just one window was rendered. But no further content was rendered after a delay of several more minutes.) Expected results: Promptly display dialog for Password, and once it is supplied promptly display all of the applications that were open at the time of the most recent Hibernation, with a responsive user interface. Additional info: ATI Mobility M4 If additional information would be helpful in localizing this bug, please ask promptly. Unless I see assurances here within a few days that I should expect good things from attempting something like: rpm -e --nodeps xorg-x11-drv-ati.i386 6.6.3-4.fc7 I intend to reinstall f7 (and deselect this update) so that I can run with a slightly more functional xorg-x11-drv-ati-6.6.3-2.fc7.i386 where at least with a quirk Hibernation can succeed. As I observed at the top of this report, this older version will also eat 100% CPU without the quirk ... but that may be a different problem, and not the same error that needs to be fixed here.
Created attachment 159229 [details] X server configuration file
Created attachment 159231 [details] X server log file
(In reply to comment #0) [nitpick for clarity] I just noticed that step 1 above in "Steps to Reproduce" was messed up; it should be: > Steps to Reproduce: > 1. System, Shutdown, Hibernate More importantly, as this bug is still with us, I have noticed that the following pair of lines are repeatedly appended to /var/log/Xorg.0.log when one is attempting to resume: (EE) R128(0): R128CCEWaitForIdle: (DEBUG) CCE idle took i = 1025 (EE) R128(0): Idle timed out, resetting engine... The longer one patiently and over-optimistically waits before restarting X, the more copies of this pair of lines are appended. These "(DEBUG) ... Idle timed out" messages are appended regardless of which suspend quirks are in effect: <merge key="power_management.quirk.vbemode_restore" type="bool">true</merge> <merge key="power_management.quirk.vbe_post" type="bool">true</merge> <merge key="power_management.quirk.vbestate_restore" type="bool">true</merge> <merge key="power_management.quirk.vga_mode_3" type="bool">true</merge> I tried Hibernate, Resume 16 times with all possible combinations of these quirks active in /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-dell.fdi and the "(DEBUG) ... Idle timed out" messages were appended each time. [u ~]$ uname -r 2.6.23.1-49.fc8 [u ~]$ rpm -q --whatprovides Xorg xorg-x11-server-Xorg-1.3.0.0-33.fc8 [u ~]$ rpm -q --whatprovides /usr/lib/xorg/modules/drivers/ati_drv.so xorg-x11-drv-ati-6.7.195-3.fc8 [u ~]$ rpm -q --whatprovides /usr/lib/xorg/modules/drivers/r128_drv.so xorg-x11-drv-ati-6.7.195-3.fc8 [u ~]$
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'. 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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
(In reply to comment #4) This bug remains with us in Fedora 9: [root@localhost ~]# uname -r 2.6.25.3-18.fc9.i686 [root@localhost ~]# rpm -q xorg-x11-drv-ati xorg-x11-drv-ati-6.8.0-14.fc9.i386 [root@localhost ~]# rpm -q xorg-x11-drv-vesa xorg-x11-drv-vesa-1.3.0-15.20080404.fc9.i386 [root@localhost ~]# Using the vesa driver, the system will successfully hibernate and resume. But with the r128 driver, resume fails as described above, still with the lines in /var/log/Xorg.0.log: (EE) R128(0): R128CCEWaitForIdle: (DEBUG) CCE idle took i = 1025 (EE) R128(0): Idle timed out, resetting engine... And /var/log/pm-suspend.log thinks all is well: Initial commandline parameters: --quirk-vbemode-restore Mon May 26 16:06:54 EDT 2008: Running hooks for hibernate. /usr/lib/pm-utils/sleep.d/00clear hibernate: success. /usr/lib/pm-utils/sleep.d/01grub hibernate: success. /usr/lib/pm-utils/sleep.d/05led hibernate: not applicable. /usr/lib/pm-utils/sleep.d/10NetworkManager hibernate: success. /usr/lib/pm-utils/sleep.d/49bluetooth hibernate: not applicable. /usr/lib/pm-utils/sleep.d/50modules hibernate: not applicable. /usr/lib/pm-utils/sleep.d/55battery hibernate: success. /usr/lib/pm-utils/sleep.d/65alsa hibernate: success. /usr/lib/pm-utils/sleep.d/90clock hibernate: Shutting down ntpd: [ OK ] success. /usr/lib/pm-utils/sleep.d/94cpufreq hibernate: success. /usr/lib/pm-utils/sleep.d/95led hibernate: not applicable. /usr/lib/pm-utils/sleep.d/95packagekit hibernate: success. /usr/lib/pm-utils/sleep.d/99hd-apm-restore.hook hibernate: saving level 128 for device sda success. /usr/lib/pm-utils/sleep.d/99video hibernate: success. Mon May 26 16:06:58 EDT 2008: performing hibernate Mon May 26 16:09:02 EDT 2008: Awake. Mon May 26 16:09:02 EDT 2008: Running hooks for thaw /usr/lib/pm-utils/sleep.d/99video thaw: success. /usr/lib/pm-utils/sleep.d/99hd-apm-restore.hook thaw: restoring level 128 for device sda /dev/sda: setting Advanced Power Management level to 0x80 (128) success. /usr/lib/pm-utils/sleep.d/95packagekit thaw: method return sender=:1.38 -> dest=:1.78 reply_serial=2 success. /usr/lib/pm-utils/sleep.d/95led thaw: not applicable. /usr/lib/pm-utils/sleep.d/94cpufreq thaw: success. /usr/lib/pm-utils/sleep.d/90clock thaw: success. /usr/lib/pm-utils/sleep.d/65alsa thaw: success. /usr/lib/pm-utils/sleep.d/55battery thaw: success. /usr/lib/pm-utils/sleep.d/50modules thaw: success. /usr/lib/pm-utils/sleep.d/49bluetooth thaw: not applicable. /usr/lib/pm-utils/sleep.d/10NetworkManager thaw: success. /usr/lib/pm-utils/sleep.d/05led thaw: not applicable. /usr/lib/pm-utils/sleep.d/01grub thaw: not applicable. /usr/lib/pm-utils/sleep.d/00clear thaw: success. Mon May 26 16:09:14 EDT 2008: Finished.
(In reply to comment #5) This bug remains with us in Fedora 10 rawhide: [u@localhost ~]$ uname -r 2.6.27-0.244.rc2.git1.fc10.i686 [u@localhost ~]$ rpm -q xorg-x11-drv-ati xorg-x11-drv-ati-6.9.0-2.fc10.i386 [u@localhost ~]$ ## which included xorg-x11-drv-r128-6.8.0-1.fc10.i386 Using the vesa driver, the system will successfully hibernate and resume. But with the r128 driver, resume fails quite similarly to the description above (e.g. one may eventually see the desktop, but it is unusable with e.g. 10 second delays to just move the cursor), with even more confirming lines in /var/log/Xorg.0.log: [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] mieqEnequeue: out-of-order valuator event; dropping. The above pair of line appears repeatedly, with some occurrences of: (EE) R128(0): R128CCEWaitForIdle: (DEBUG) CCE idle took i = 1025 (EE) R128(0): Idle timed out, resetting engine... sprinkled among them.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Disabling dri in xorg.conf and using the vbestate-restore quirk fixes resume for me. The only problem seems to be xvideo, which requires restarting Xorg to actually show a picture. The card is (--) R128(0): Chipset: "ATI Rage 128 Pro GL PF (AGP)" (ChipID = 0x5046)
Any progress on this in rawhide?
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.