Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 539367

Summary: pm-suspend locks solid on ThinkPad R51 (Intel chipset)
Product: [Fedora] Fedora Reporter: Ian Collier <imc>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: dougsland, gansalmon, ghthor, harryc56, itamar, kernel-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-06 17:09:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
pm-suspend.log (in verbose shell mode)
none
lspci -nn -vv
none
kernel warnings while suspending the machine in Fedora 13 none

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