Bug 539367 - pm-suspend locks solid on ThinkPad R51 (Intel chipset)
Summary: pm-suspend locks solid on ThinkPad R51 (Intel chipset)
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-19 23:13 UTC by Ian Collier
Modified: 2011-06-06 17:09 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-06 17:09:03 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
pm-suspend.log (in verbose shell mode) (26.92 KB, text/plain)
2009-11-19 23:13 UTC, Ian Collier
no flags Details
lspci -nn -vv (10.90 KB, text/plain)
2009-11-19 23:14 UTC, Ian Collier
no flags Details
kernel warnings while suspending the machine in Fedora 13 (3.10 KB, text/plain)
2010-05-29 22:03 UTC, Ian Collier
no flags Details

Description Ian Collier 2009-11-19 23:13:07 UTC
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):
kernel-2.6.31.5-127.fc12.i686
pm-utils-1.2.5-6.fc12.i686

Comment 1 Ian Collier 2009-11-19 23:14:33 UTC
Created attachment 372374 [details]
lspci -nn -vv

Comment 2 Ian Collier 2009-11-19 23:17:45 UTC
PS it's probably not relevant but I fixed bug 496026 on my system before generating the above pm-suspend.log.

Comment 3 Ian Collier 2009-11-20 00:05:45 UTC
OK so I tried single user mode with nomodeset.  It worked fine, so this would seem to be another KMS bug.

Comment 4 Ian Collier 2010-03-18 11:46:36 UTC
Now up to kernel 2.6.32.9-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).

Comment 5 Ian Collier 2010-05-29 22:03:46 UTC
Created attachment 417926 [details]
kernel warnings while suspending the machine in Fedora 13

Upgraded to Fedora 13 and kernel 2.6.33.4-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.

Comment 6 Ian Collier 2010-08-05 13:35:37 UTC
The last two times I've tried to suspend it have crashed.  The second of these was with kernel 2.6.33.6-147.fc13.

Comment 7 Ian Collier 2010-09-07 22:46:13 UTC
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.

Comment 8 Ian Collier 2010-11-04 00:51:00 UTC
Updated to kernel-2.6.34.7-61.fc13.i686 - back to 100% failure.

However... have now upgraded to Fedora 14 and 2.6.35.6-48.fc14.i686;
first four attempts have all succeeded (even after closing the lid),
so looks like this might be fixed in F14.

Comment 9 Bug Zapper 2011-06-02 17:21:03 UTC
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


Note You need to log in before you can comment on or make changes to this bug.