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: Always. 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.)
Created attachment 154357 [details] sysreport output This is for my DELL 490.
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).
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. Bill
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 ram). 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. Nigel
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 impatient. 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. Bill
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. Bill
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.
As a diagnostic, I installed Fedora 7 suspend to ram. It works perfectly on that platform.
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 http://people.redhat.com/linville/kernels/rhel5/.
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.