Description of problem: Running pm-suspend puts my Lenovo Thinkstation D20 desktop computer into suspend mode (fans whir down, but power light is blinking), but pushing the power button to try and recover hangs. I reproduced the problem with both the F15 test day image and a RHEL 6 kernel; it happened regardless of whether I booted into runlevel 3 and used a console or into runlevel 5 and issued the command from an xterm. Version-Release number of selected component (if applicable): Fedora 15 kernel from graphics test day livecd image: kernel-2.6.38-0.rc5.git5.1.fc15.x86_64 RHEL 6 kernel from hard drive install: kernel-2.6.32-114.0.1.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. su -c pm-suspend 2. wait 30 seconds 3. push power button Actual results: Fedora 15 test day kernel just gives a blank screen with a blinking cursor in the top right; I waited more than 10 minutes. RHEL kernel was in a blank screen for a minute, then displayed text, ending with: sd 0:0:0:0: [sda] START_STOP FAILED sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT PM: Device 0:0:0:0 failed to resume: error 100663296 Restarting tasks ... done. In both cases, there was no further response from the computer; ctrl-alt-delete didn't work, and I had to power cycle to recover. Expected results: Recover from suspend without problems. Additional info: My smolt profile: http://www.smolts.org/client/show/pub_9b49d403-6244-4523-a2ba-8844f18d2aa6 Let me know what else I should try to help you debug things; I'm not very familiar with kernel debugging.
2.6.38 is pretty old at this point. Does this still happen with 2.6.43/3.3 in F15/F16?
My thinkstation D20 is currently in storage for a couple of weeks; I will have to retest this on F17 when I get a chance to boot it back up.
I have same machine as Eric's and have same resume problem from hibernate/suspend. I reported it as in bug 771142. The problem persists through kernel 3.5-rc3.
I have my machine back up, and retested it today with 32-bit Fedora 17, using kernel-3.5.0-2.fc17.i686; the symptoms are still the same. I validated that the machine has 10G swap and only 8G memory, so that shouldn't be the problem. I have the machine set up to triple boot (64-bit rawhide, 32-bit Fedora, and 64-bit RHEL 6). What else do you need me to do?
Once again, I reproduced this on rawhide during the F18 power test day. I also noticed that if I suspended from a terminal (such as using ctrl-alt-f3 before issuing pm-suspend, rather than doing it from a terminal inside gnome-shell), then I could get back to the screen image of that terminal just before the suspend, by typing ctrl-alt-f3, but even then, I had no further response (no prompt, could not switch to any other terminal, ctrl-alt-del had no effect).
(In reply to comment #5) > Once again, I reproduced this on rawhide during the F18 power test day. https://fedoraproject.org/wiki/Test_Day:2012-10-11_Power_Management#Test_Results kernel-3.7.0-0.rc0.git5.2.fc19.x86_64
Breakthrough: I remembered that back in the F12 days, I had issues with this same machine even booting into Linux kernels, and bug 616178 ultimately traced it to a kernel bug in the mvsas code on second boots. Well, waking up from pm-suspend must be triggering a similar bug, because I did the following: 1. with the disk in, boot the F18 power test day liveusb image 2. pm-suspend 3. push power button - system is hung 4. power down, remove the hard disk 5. boot the F18 power test day liveusb image 6. pm-suspend 7. push power button - voila - it recovered
Also, the fact that bug 865597 noticed lots of I/O errors after attempting to wake up from a pm-hibernate again makes me think that the root cause of this problem is a bug in the driver for the particular SATA controller for my hard disk.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Is this still an issue with the 3.9 kernels in F19?
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.