| Summary: | failure to recover from suspend on lenovo thinkstation D20 if hard disk is present | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Eric Blake <eblake> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 19 | CC: | andyzhu35, eblake, gansalmon, itamar, jforbes, jonathan, kernel-maint, laine, madhu.chinakonda |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | first=2.6.38 tested=2.6.38 suspend | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-04-23 17:27:24 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | 616178 | ||
| Bug Blocks: | 865597 | ||
|
Description
Eric Blake
2011-02-23 02:48:44 UTC
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. |