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
Version-Release number of selected component (if applicable):
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.
I hear some beeps, and the computer fan running. No signal to the monitor.
For the computer to resume where it left off.
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.)
Created attachment 154357 [details]
This is for my DELL 490.
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).
Will reassign to me since it sounds like a kernel issue.
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.
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.
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.
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
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.
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
As a diagnostic, I installed Fedora 7 suspend to ram. It works perfectly on
Ok. Shall we close as fixed in next RHEL5 kernel release then?
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.
They're not up-to-the-minute, but I'd try a kernel from
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.
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.
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).
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.
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.