Bug 248180

Summary: Xorg ~100% CPU upon resume from hibernation
Product: [Fedora] Fedora Reporter: xunilarodef
Component: xorg-x11-drv-r128Assignee: Dave Airlie <airlied>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 10CC: mlichvar, nemesis, poelstra, triage, vedran, xgl-maint
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-12-18 05:57:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
X server configuration file
none
X server log file none

Description xunilarodef 2007-07-13 18:39:48 UTC 
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.
Comment 1 xunilarodef 2007-07-13 18:39:49 UTC 
Created attachment 159229 [details]
X server configuration file
Comment 2 xunilarodef 2007-07-13 18:45:37 UTC 
Created attachment 159231 [details]
X server log file
Comment 3 xunilarodef 2007-11-26 13:23:11 UTC 
(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 ~]$
Comment 4 Bug Zapper 2008-05-14 13:32:22 UTC 
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
Comment 5 xunilarodef 2008-05-26 20:53:22 UTC 
(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.
Comment 6 xunilarodef 2008-08-21 11:24:51 UTC 
(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.
Comment 7 Bug Zapper 2008-11-26 01:57:17 UTC 
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
Comment 8 Miroslav Lichvar 2009-01-11 13:04:17 UTC 
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)
Comment 9 Vedran Miletić 2009-09-06 09:27:20 UTC 
Any progress on this in rawhide?
Comment 10 Bug Zapper 2009-11-18 09:32:12 UTC 
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
Comment 11 Bug Zapper 2009-12-18 05:57:08 UTC 
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.