Red Hat Bugzilla – Bug 539367
pm-suspend locks solid on ThinkPad R51 (Intel chipset)
Last modified: 2011-06-06 13:09:03 EDT
Created attachment 372372 [details]
pm-suspend.log (in verbose shell mode)
Description of problem:
System ceases functioning without fail on the way down if pm-suspend is executed.
pm-suspend.log shows that it got all the way to "echo mem > /sys/power/state" so the problem happens after userspace hands over control to the kernel. When it crashes, the screen is still active and the suspend LED is blinking. Nothing except a forced power-off will revive it.
If this is done on a (KMS) text console in single-user mode, the screen contents before the crash remain visible when the system locks up. In theory you could see any messages output during the suspend process; however, there are none either on the screen or in the message log.
It's not practical to attempt this with nomodeset because xorg kills the machine dead (I guess it could be tried in single-user mode, but that wouldn't be much use in general since working without X isn't really an option).
In Fedora Core 6, pm-suspend worked almost flawlessly (though I had to hack at it quite a lot to achieve that).
In Fedora 10, pm-suspend successfully put the machine to sleep and allowed it to wake up, but the graphics was kaput afterwards.
It seems to be getting steadily worse, not better...
Version-Release number of selected component (if applicable):
Created attachment 372374 [details]
lspci -nn -vv
PS it's probably not relevant but I fixed bug 496026 on my system before generating the above pm-suspend.log.
OK so I tried single user mode with nomodeset. It worked fine, so this would seem to be another KMS bug.
Now up to kernel 18.104.22.168-70.fc12.i686 and it still doesn't work (and I can't hibernate either - this means I have to shut down my laptop in order to transport it, which is seriously inconvenient).
Created attachment 417926 [details]
kernel warnings while suspending the machine in Fedora 13
Upgraded to Fedora 13 and kernel 22.214.171.124-95.fc13.i686.
pm-suspend has still crashed in the same manner, but is now sometimes successful. In fact, in tests I've had more successes than failures. Some of the tests cause the attached kernel warning to be written to the syslog just before userspace is frozen - I'm not sure if it's relevant to this problem.
The last two times I've tried to suspend it have crashed. The second of these was with kernel 126.96.36.199-147.fc13.
I've discovered some more info about what makes this fail, as last weekend I had several successful suspend-resume cycles.
I have gnome-power-manager set not to suspend when the lid is closed - mostly because I often leave stuff running but it's tidier if I close the lid while I'm not at the keyboard. But also because suspending is unreliable at the moment.
It turns out that suspending is successful until the first time I close and reopen the lid with the system running. After that, any attempt to suspend the machine will crash.
Updated to kernel-188.8.131.52-61.fc13.i686 - back to 100% failure.
However... have now upgraded to Fedora 14 and 184.108.40.206-48.fc14.i686;
first four attempts have all succeeded (even after closing the lid),
so looks like this might be fixed in F14.
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '13'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 13's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 13 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here: