Red Hat Bugzilla – Bug 251080
Resume after suspend often doesn't work [with compiz]
Last modified: 2014-09-15 07:31:01 EDT
Description of problem: Fairly frequently, fedora 7 doesn't come out of suspend successfully. It just sits there with a black screen. Version-Release number of selected component (if applicable): 2.6.22.1-41.fc7 How reproducible: Intermittent Steps to Reproduce: 1. Suspend 2. Awake 3. Occasionally it doesn't work Actual results: Occasionally just a black screen, no awake from suspend. Have to hold down the power button to power down and then restart. I'm afraid I don't have any great log entries to show what happens in this case, but for a copy of a recent /var/log/messages see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250677 Perhaps this case and the one linked above are related??? I do have an ATI video chipset (ATI Mobility Radeon 9700). Expected results: Successfully comes out of suspend every time.
I have similar intermittent problems on my Dell Latitude D610: with kernel 2.6.22.1-41.fc7.i686 and 2.6.22.1-33.fc7.i686 Suspend/Resume worked seamlessly on FC6. I can attach confs and logs if required, but as yet haven't been able to find anything that would indicate why the laptop won't resume in the logs, but will keep looking.
Created attachment 160802 [details] /var/log/pm-suspend.log
Comment on attachment 160802 [details] /var/log/pm-suspend.log The most recent failure log.
I'm having a similar problem on an IBM T42 thinkpad. Suspend works perfectly on 2.6.22.1-33.fc7 Suspend fails consistently on 2.6.22.1-41.fc7 -- When suspend fails the "standby" (half moon) led blinks and led#0 is on solid.
kernel-2.6.22.2-52.fc7 is in updates-testing, can someone try that?
And please post the contents of /usr/lib/pm-utils/sleep.d/94cpufreq
(In reply to comment #5) > kernel-2.6.22.2-52.fc7 is in updates-testing, can someone try that? > No luck there. Still having problems.
Created attachment 161248 [details] Contents of /usr/lib/pm-utils/sleep.d/94cpufreq As requested.
In case anyone's interested, I can confirm the same behaviour on kernel-2.6.22.4-65.fc7 Again the pm-suspend.log ends with running hook 94cpufreq and I have extracted the following from /var/log/messages: Aug 27 22:10:52 blackbird gnome-power-manager: (richardg) Suspending computer because the lid has been closed on battery power Aug 27 22:10:53 blackbird NetworkManager: <info> Going to sleep. Aug 27 22:10:53 blackbird NetworkManager: <info> nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device eth1 link now 0 Aug 27 22:10:54 blackbird NetworkManager: <info> nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device eth0 link now 0 Aug 27 22:10:54 blackbird NetworkManager: <info> nm-device-802-3-ethernet.c - link_deactivated_helper (129) device eth0 will set active link to FALSE Aug 27 22:10:54 blackbird NetworkManager: <info> nm-device-802-3-ethernet.c - nm_device_802_3_ethernet_link_deactivated (149) device eth0 scheduled link_deactivated_helper Aug 27 22:10:54 blackbird NetworkManager: <info> Error getting killswitch power: org.freedesktop.Hal.Device.KillSwitch.NotSupported - Access type not supported Aug 27 22:10:55 blackbird ntpd[13879]: ntpd exiting on signal 15 Aug 28 08:49:13 blackbird restorecond: Read error (Interrupted system call) Aug 28 08:49:14 blackbird kernel: Stopping tasks ... done. Aug 28 08:49:14 blackbird kernel: Suspending console(s) Aug 28 08:56:29 blackbird syslogd 1.4.2: restart. ... so at 22:10 I shut the lid to trigger suspend, at 08:49 I opened the lid to trigger wake-up (and for whatever reason syslog logs the last few messages sent before suspend) and at 08:56 I had to hard power-off and power-on again to bring it back to life. At this point it seems to fail more often when it has been suspended for long periods of time e.g. overnight.
Yes, I agree with that comment...seems to fail more when I resume in the morning after suspending the evening before than resuming the same day. Couldn't be anything to do with the change of date???
It would seem that installing pm-utils-0.99.4-3.fc8.i386 from the dev. repo. has solved this problem for me. I haven't exactly 'soak' tested it, only having installed the new package yesterday morning, but it hasn't failed yet. Of course, it could also be that vbetool and radeontool packages were installed with the new version of pm-utils (it was complaining about no vbetool in the earlier version)... Perhaps this may help you too David.
This problem still apparently in f8 I very frequently suspend and then on resume it frustratingly locks up so end up having to hold the power button down to forcibly shut it down and then reboot.
Apparent on 2.6.23.1-49.fc8
This seems related to suspending when running compiz, as I haven't seen it when running metacity.
In reply to comment #14) > This seems related to suspending when running compiz, as I haven't seen it when > running metacity. > Richard, Steve, Is this also the case for you?
(In reply to comment #15) > In reply to comment #14) > > This seems related to suspending when running compiz, as I haven't seen it when > > running metacity. > > > > Richard, Steve, > > Is this also the case for you?j Nope, I've been running compiz-fusion the whole time. I haven't had this problem for ages! Not since I last posted... https://bugzilla.redhat.com/show_bug.cgi?id=251080#c11
I've been running metacity to avoid this problem, but I notice there has been a compiz-fusion newer release so I'll switch back to using compiz-fusion and report soon whether it happens for me.
Yesterday I went to shut my computer down to suspend at the end of the day from running compiz-fusion. It never did suspend. I got a black text-mode screen with a flashing cursor that just sat there for ages. I ended up having to hold down the power button for a few seconds to force the system to shut down and then cope with filesystem journal recoveries on subsequent boot.... This doesn't happen when not running compiz-fusion. This isn't exactly the same problem symptom as defined by this case, but something is still broken with compiz-fusion.
What about just regular compiz? What graphics driver are you using?
The graphics driver I'm using is 'radeon' and the hardware is ATI Mobility Radeon 9700. I'm using "desktop effects", whatever that is, whether that is compiz or compiz fusion (I am blissfully unaware though I wish I wasn't), though I do have compiz-fusion packages installed. More info below: [dcampbel@host15-101 Downloads]$ ps aux | grep compiz dcampbel 3104 0.7 0.4 18312 9112 ? S 00:30 0:11 compiz --sm-client-id default1 glib gconf [root@host15-101 ~]# rpm -q -a | grep compiz compiz-gnome-0.6.2-3.fc8 compiz-fusion-extras-gnome-0.6.0-1.fc8 compiz-fusion-gnome-0.6.0-12.fc8 compizconfig-python-0.6.0.1-2.fc8 compiz-fusion-0.6.0-12.fc8 gnome-compiz-manager-0.10.4-3.fc8 compiz-bcop-0.6.0-1.fc8 libcompizconfig-0.6.0-3.fc8 compiz-0.6.2-3.fc8 compiz-fusion-extras-0.6.0-1.fc8 compiz-manager-0.6.0-4.fc8
Created attachment 294026 [details] output of dmesg I just tried to shut down to suspend again. This time the screen went to text mode and got a flashing cursor for a while, and then it seemed to give up and come back to X. I'm attaching the output of dmesg, which indicates a whole lot of kernel stack traces which has flooded the whole kernel ring buffer.
Desktop-effects is compiz, compiz-fusion is the old beryl project. You'll want to use one or the other. Desktop-effects enables compiz whereas a separate manager enables and disables compiz-fusion. # yum remove compiz-fusion* Not that I believe that will solve your suspend/resume problem however. You should review: http://fedoraproject.org/wiki/KernelCommonProblems as running some of the steps there and posting back with output would also help.
Issue confirmed on Fedora 9, 2.6.25 kernel, VESA driver(!). Actually suspend never worked for me on Linux, neither with nor without the proper VGA drivers, neither with nor without compiz. My Windows systems handle this well. (If any info needed, tell me)
Fedora 9 comes with a new Xorg and new drivers. I've always used i810 driver, and now in F9 it is not supported anymore. Once I switched to the intel driver F9 started to fail after suspend, but not the same way described here. Could you pls take a look at my issue to see if it a duplicate of yours? It's not just a resume/suspend, it's about acceleration driver failures after suspend/resume: https://bugzilla.redhat.com/show_bug.cgi?id=441334
I think it's not a duplicate, I don't even get to the "after suspend" part. My system is simply incompatible with the suspend/resume code, the hardwares spin up, but then nothing else than black screen and flashing Numlock. I only managed once in my life to get it back from suspend, for one minute. I got the desktop, then it froze step by step until after a minute, nothing worked. (Maybe that was an old Debian, I don't know) Nowadays I don't even try with compiz. If it fails with both the proprietary VGA drivers and the VESA driver, then I can do nothing. I repeat, I never had any real success with suspend, with virtually ANY Linux system, no Fedora 8, no F9, no Suse, no Ubuntu, no Gentoo, nothing. Only Windowses. And no, I'm not working for MS :) So, if anyone has a brand new kernel with a brand new suspend code which he thinks is bulletproof, just send it to me.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. 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 '8'. 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 8'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 8 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
Would it be safe to test a Fedora 10 or Rawhide kernel directly on an otherwise Fedora 9 install? If not, then perhaps it would be a good idea to test suspend/resume with a Fedora 11 Beta Live CD or Live USB: http://fedoraproject.org/wiki/How_to_create_and_use_a_Live_CD http://fedoraproject.org/wiki/How_to_create_and_use_Live_USB Lots of chances are made in the kernel with major version updates, and this problem might already be fixed.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. 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 '9'. 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 9'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 9 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
I'm on F11. Without compiz, it seems to work, but since I don't have a chance to get compiz working on my ATI card in a while because of driver issues, I can't test it now.
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.