Bug 251080 - Resume after suspend often doesn't work [with compiz]
Summary: Resume after suspend often doesn't work [with compiz]
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 9
Hardware: All
OS: Linux
low
urgent
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-08-06 23:00 UTC by David Campbell
Modified: 2014-09-15 11:31 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-07-14 15:39:40 UTC
Type: ---
Embargoed:
david: needinfo-


Attachments (Terms of Use)
/var/log/pm-suspend.log (1.77 KB, text/plain)
2007-08-07 08:13 UTC, Richard Guest
no flags Details
Contents of /usr/lib/pm-utils/sleep.d/94cpufreq (994 bytes, text/plain)
2007-08-14 06:25 UTC, Richard Guest
no flags Details
output of dmesg (120.02 KB, text/plain)
2008-02-05 18:02 UTC, David Campbell
no flags Details

Description David Campbell 2007-08-06 23:00:13 UTC
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.

Comment 1 Richard Guest 2007-08-06 23:31:22 UTC
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.

Comment 2 Richard Guest 2007-08-07 08:13:30 UTC
Created attachment 160802 [details]
/var/log/pm-suspend.log

Comment 3 Richard Guest 2007-08-07 08:37:48 UTC
Comment on attachment 160802 [details]
/var/log/pm-suspend.log

The most recent failure log.

Comment 4 Stephen J Alexander 2007-08-13 21:57:43 UTC
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.


Comment 5 Chuck Ebbert 2007-08-13 22:06:36 UTC
kernel-2.6.22.2-52.fc7 is in updates-testing, can someone try that?


Comment 6 Chuck Ebbert 2007-08-13 22:10:11 UTC
And please post the contents of /usr/lib/pm-utils/sleep.d/94cpufreq

Comment 7 Richard Guest 2007-08-14 06:21:17 UTC
(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.

Comment 8 Richard Guest 2007-08-14 06:25:30 UTC
Created attachment 161248 [details]
Contents of /usr/lib/pm-utils/sleep.d/94cpufreq

As requested.

Comment 9 Richard Guest 2007-08-27 22:40:13 UTC
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.

Comment 10 David Campbell 2007-08-27 23:45:56 UTC
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???


Comment 11 Richard Guest 2007-09-21 23:49:43 UTC
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.

Comment 12 David Campbell 2007-11-20 04:19:46 UTC
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.


Comment 13 David Campbell 2007-11-20 04:20:48 UTC
Apparent on 2.6.23.1-49.fc8

Comment 14 David Campbell 2008-01-15 05:54:10 UTC
This seems related to suspending when running compiz, as I haven't seen it when
running metacity.


Comment 15 Christopher Brown 2008-02-03 22:11:15 UTC
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?


Comment 16 Richard Guest 2008-02-03 22:18:52 UTC
(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

Comment 17 David Campbell 2008-02-03 22:38:04 UTC
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.


Comment 18 David Campbell 2008-02-05 03:54:37 UTC
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.


Comment 19 Christopher Brown 2008-02-05 14:37:28 UTC
What about just regular compiz? What graphics driver are you using?

Comment 20 David Campbell 2008-02-05 15:33:48 UTC
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


Comment 21 David Campbell 2008-02-05 18:02:20 UTC
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.

Comment 22 Christopher Brown 2008-02-06 01:05:52 UTC
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.

Comment 23 Viktor Erdelyi 2008-05-14 22:15:46 UTC
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)

Comment 24 Oleg Mikheev 2008-05-22 20:44:35 UTC
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

Comment 25 Viktor Erdelyi 2008-05-22 21:34:42 UTC
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.

Comment 26 Bug Zapper 2008-11-26 07:39:00 UTC
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

Comment 27 Christopher Beland 2009-04-22 21:20:45 UTC
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.

Comment 28 Bug Zapper 2009-06-09 22:44:46 UTC
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

Comment 29 Viktor Erdelyi 2009-06-10 07:30:41 UTC
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.

Comment 30 Bug Zapper 2009-07-14 15:39:40 UTC
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.


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