Bug 239377 - Failes to resume from hibernate or suspend.
Summary: Failes to resume from hibernate or suspend.
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gnome-power-manager   
(Show other bugs)
Version: 5.0
Hardware: ia64
OS: Linux
Target Milestone: ---
: ---
Assignee: Linda Wang
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-05-07 23:31 UTC by Bill C. Riemers
Modified: 2014-06-16 13:44 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-06-02 13:05:31 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
sysreport output (507.19 KB, application/octet-stream)
2007-05-08 19:50 UTC, Bill C. Riemers
no flags Details

Description Bill C. Riemers 2007-05-07 23:31:45 UTC
Description of problem:

On my DELL 490, whenever I try to sleep or hibernate my system, it fails to
resume.  Sometimes it just cycles directly through the hibernate to the restart
sequence where it fails to resume.  Other times it will put the system to sleep.
 When I press the power button I hear the computer working, but I never see
anything on the monitor...

I thought maybe the problem was with one of the drivers not playing nicely.  So
I tried booting to runlevel 1 and then running /sbin/pm-suspend.  The same
behavior happened.

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

How reproducible:


To reproduce with the fewest dependencies:

Steps to Reproduce: 
1.  Boot to runlevel 1.
2.  From the shell prompt, run /sbin/pm-suspend.
3.  Wait a few minutes to make sure everything is finished.
4.  Push the power button to "wake-up" the computer.
Steps to reproduce from Gnome:
1. Use System - Suspend.
2. Wait a few minutes to make sure everything is finished.
3. Push the power button to "wake-up" the computer.

Actual results:

I hear some beeps, and the computer fan running.  No signal to the monitor.

Expected results:

For the computer to resume where it left off.

Additional info:

I do not know if the following is helpful.

I experienced a similar problem about a year ago on a different linux version
and a different computer.  I was told on the suspend2 mailing list the problem
was USB could not be suspended, and since I used a USB mouse and keyboard there
was no way to wakeup the computer again.  I am still using the same USB mouse
and keyboard.  (Both are the only types that don't hurt my hands.)

Comment 1 Bill C. Riemers 2007-05-08 19:50:32 UTC
Created attachment 154357 [details]
sysreport output

This is for my DELL 490.

Comment 2 Nigel Cunningham 2007-05-14 23:24:32 UTC
Hi Bill.

USB power management support has improved since then, so if you're using a
reasonably recent kernel, you might have more success.

This report seems to confuse suspend to ram and to disk. Could you please open a
separate report for each, since they're very different creatures? I'll then help
you with the suspend to disk issue(s).

Comment 3 Nigel Cunningham 2007-05-18 22:49:16 UTC
Will reassign to me since it sounds like a kernel issue.

Comment 4 Bill C. Riemers 2007-05-21 14:29:02 UTC
Hi Nigel,  I intended this report to just cover suspend-to-ram.  
Suspend-to-disk also fails, but I did not include that information in this
report.  Since you think that is useful, I report details on what happens when I
suspend to disk in a separate report.

I am pretty much stuck using the kernels pushed out for RHEL5.  But if you think
it is a useful diagnosis I can install Fedora 7 when it is released this week as
a separate boot option and see if that suspends correctly.


Comment 5 Nigel Cunningham 2007-05-21 23:13:33 UTC
You confused me a bit, because you talk in the initial message about hibernation
and waiting a few minutes for it to complete (sounds like swsusp, not suspend to

When you suspend to ram, and hear the computer working but see nothing on the
monitor, could you try "cd /; find" and see if the hard drive light reflects
that the computer runs that command? If that's the case, we can probably say
it's just an issue with getting video going again, and continue from there.


Comment 6 Bill C. Riemers 2007-05-24 14:56:18 UTC
The waiting for a few minutes is just because I'm not certain how long suspend
to ram is suppose to take.  I would hate to see failures, just because I am

Generally, the computer will respond to the keyboard after it "wakes up".  i.e.
If I suspend from run level 3, then when it wakes up I can do a
"ctrl-alt-delete" to cause a reboot.  I don't have a visible disk light to see
if the disk drive is responding.  But I could try ssh'ing to the box from a
different machine to see if the network comes back up.


Comment 7 Bill C. Riemers 2007-05-24 15:20:32 UTC
I hate to have to correct myself, but the previous information I supplied is wrong.

If I suspend from runlevel 3 with the command pm-suspend, after I wake-up the
computer it does not respond to keyboard, and it does not respond to even
network pings.

If I suspend from runlevel 5 using the GNOME System menu option, after I wake-up
I can usually get the computer to respond to CTRL-ALT-F1 followed by
CTRL-ALT-DELETE to do a clean reboot.  The computer still does not respond to
the network pings.

Once, and only once, I the GUI actually restarted after suspending from runlevel
5.  The display lasted long enough for me to unlock the screensaver.  Then my
left monitor started to go "funky" like it was trying to auto-adjust video
modes, and the mouse froze.  The right monitor remained with a crystal clear
picture, but was also frozen.  I could not get the computer to respond to the
keyboard or network, so I had to do a cold boot.

Normally, I would blame the runlevel 5 problems on the nvidia driver.  But I
can't explain the problem with runlevel 3 or runlevel 1, where the nvidia driver
has not been loaded.


Comment 8 Nigel Cunningham 2007-05-28 23:50:32 UTC
I think we should just wait a bit for Dave Jones to commit some suspend fixes
he's sitting on. I'm not sure why he's sitting on them, and have just pinged him
on IRC.

Comment 9 Bill C. Riemers 2007-06-10 14:37:58 UTC
As a diagnostic, I installed Fedora 7 suspend to ram.  It works perfectly on
that platform.  

Comment 10 Nigel Cunningham 2007-06-12 09:48:47 UTC
Ok. Shall we close as fixed in next RHEL5 kernel release then?

Comment 11 Bill C. Riemers 2007-06-13 14:18:07 UTC
Since the RHEL kernels are always older than the Fedora kernels, there is a
chance the back ported fixes won't work.  If you have a test build of the rpm, I
can verify it.

Comment 12 Nigel Cunningham 2007-06-19 00:25:30 UTC
They're not up-to-the-minute, but I'd try a kernel from 

Comment 13 Bill C. Riemers 2007-06-20 15:49:29 UTC
The 2.6.18-26.el5.jwltest kernel has the exact same problem with suspend not
resuming.  This in not surprising since I did not see any backport patches of
2.6.21 suspend/resume fixes listed as part of the linville 2.6.18 kernels.

Comment 15 RHEL Product and Program Management 2014-03-07 13:37:22 UTC
This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug.

Comment 16 RHEL Product and Program Management 2014-06-02 13:05:31 UTC
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support).

Comment 17 Bill C. Riemers 2014-06-16 13:41:41 UTC
Wow.  I was surprised to see this need info request show-up in my e-mail today.  I haven't used RHEL 5 since 2007.   RHEL 6 and later versions of Fedora do not have this issue, so I completely forgot about this report.

Comment 18 Bill C. Riemers 2014-06-16 13:44:14 UTC
It looks like the problem is there was a bug back in the RHEL Product and Program Management update in March where it toggled every single old bug back to a need info state.   That makes no sense for closed issues, but it does explain why I got spammed with need info reminders today.

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