Bug 499047 - regression: 2.6.29.x kernels crash upon 2nd suspend resume attempt
regression: 2.6.29.x kernels crash upon 2nd suspend resume attempt
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Regression
: 507652 (view as bug list)
Depends On:
Blocks: 513462
  Show dependency treegraph
Reported: 2009-05-04 19:26 EDT by Steven Bularca
Modified: 2010-05-03 01:17 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 499651
Last Closed: 2010-05-03 01:17:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Steven Bularca 2009-05-04 19:26:08 EDT
Description of problem:
the latest 2.6.27.x kernels are working just fine for my HP pavilion dv1657cl laptop with intel i915 graphics processor.  Whenever I test out the and series of kernels from koji, the kernel crashes after the second suspend/resume cycle.

Version-Release number of selected component (if applicable):
kernel 2.6.29.x

How reproducible:

Steps to Reproduce:
1. Suspend
2. Wake up
3. Suspend again
4. Try to wake up again

Actual results:
HDD I/O LED remains on.  LCD is black and the backlight never comes on.  Keyboard is unresponsive.  Only a hard reboot will bring the computer back to life.

Expected results:
The computer should suspend and wake up every time without issues.

Additional info:
Upon hard reboot, kerneloops reports a crash signature and sends the data to kerneloops.org.  I don't know how to retrieve this crash signature so until I figure that out I cannot provide any more information in that regard.  It should be noted however, that suspend and resume works perfectly fine on a different laptop of mine (HP pavilion dv9009nr - amd/nvidia), so it must be a specific issue with whatever modules this hardware uses (maybe i915, maybe something else -- my knowledge of this stuff is limited).
Comment 1 Steven Bularca 2009-06-19 02:39:54 EDT
This bug still persists in F11, so changing this bug to version 11.
Comment 2 Chuck Ebbert 2009-06-20 06:31:48 EDT
Try disabling the cpuspeed service.
Comment 3 Pádraig Brady 2009-06-20 09:36:48 EDT
To clarify, bug 499651 sounds very much like the same issue. As stated there, disabling the cpuspeed service works for me. Note a reboot is required after doing that (or one can manually stop the service and rmmod acpi_cpufreq).
Comment 4 Steven Bularca 2009-06-20 19:22:01 EDT
This workaround did not seem to work.  Here is what I did:

(as root)

service cpuspeed stop

rmmod acpi_cpufreq

then I tried to suspend the system... it suspended fine.  When I tried to resume however, the screen came on but the machine was completely locked up.  After rebooting I got this oops message:

Kernel failure message 1:
BUG: sleeping function called from invalid context at kernel/workqueue.c:440
in_atomic(): 0, irqs_disabled(): 1, pid: 9221, name: pm-hibernate
Pid: 9221, comm: pm-hibernate Tainted: G        W #1
Call Trace:

And that's it.  No "trace" appears under 'Call Trace:'
Comment 5 Steven Bularca 2009-07-02 18:12:28 EDT
After additional testing,

The same symptoms are experienced for both suspend to RAM and suspend to disk.  There appears to be no problem suspending while in init 3 (it works every time, all the time), but when using init 5, it usually works once, then always freezes the system when resuming for the 2nd time.
Comment 6 Ronald Kuetemeier 2009-07-10 18:22:15 EDT
Had the same problem on a Acer Aspire 3610. But hibernate worked well all the time, so I used that until I had time to check the bug system.

Used the work around from  Bug 499651:

Don't forget to do:
chkconfig cpuspeed off

/etc/init.d/cpuspeed stop
rmmod acpi_cpufreq

otherwise the system will reload the service after boot.

lspci -vk:

00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03)
	Subsystem: Acer Incorporated [ALI] Device 006a
	Flags: bus master, fast devsel, latency 0
	Capabilities: [e0] Vendor Specific Information <?>
	Kernel driver in use: agpgart-intel

00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) (prog-if 00 [VGA controller])
	Subsystem: Acer Incorporated [ALI] Device 006a
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Memory at b0080000 (32-bit, non-prefetchable) [size=512K]
	I/O ports at 1800 [size=8]
	Memory at c0000000 (32-bit, prefetchable) [size=256M]
	Memory at b0000000 (32-bit, non-prefetchable) [size=256K]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [d0] Power Management version 2
	Kernel driver in use: i915
	Kernel modules: i915

00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
	Subsystem: Acer Incorporated [ALI] Device 006a
	Flags: fast devsel
	Memory at 6c000000 (32-bit, non-prefetchable) [disabled] [size=512K]
	Capabilities: [d0] Power Management version 2
Comment 7 Steven Bularca 2009-07-10 18:59:13 EDT

This bug *appears* to be fixed in the latest rawhide kernel build:



Now my suspend to ram works fine, and the suspend to disk works but the X session crashes and I Have to log in again.
Comment 8 Samuel Sieb 2009-07-12 01:42:28 EDT
Removing the acpi_cpufreq module fixes my crash on second resume as well.
Comment 9 Walter Neumann 2009-08-05 13:09:35 EDT
Adding the following 75cpuspeed script to /etc/pm/sleep.d is a solution:


case "$1" in
	        /sbin/service cpuspeed stop
		/sbin/rmmod acpi_cpufreq
		/sbin/service cpuspeed start
		modprobe acpi_cpufreq 
	*) exit $NA
Comment 10 Richard Hughes 2009-08-20 08:00:00 EDT
*** Bug 507652 has been marked as a duplicate of this bug. ***
Comment 11 Cosimo Cecchi 2009-09-10 13:07:36 EDT
This seems fixed for me with recent F11 kernels.
Comment 12 Bug Zapper 2010-04-27 10:07:27 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  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 '11'.

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 11'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 11 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: 
Comment 13 Walter Neumann 2010-04-27 13:30:14 EDT
I confirm that this is fixed with current kernels. I didn't report the bug, so I can't change its status, but someone should mark it FIXED
Comment 14 Alex Lancaster 2010-05-03 01:17:16 EDT
(In reply to comment #13)
> I confirm that this is fixed with current kernels. I didn't report the bug, so
> I can't change its status, but someone should mark it FIXED    

Confirming this with my current kernel on F-11 (kernel-  Closing bug.  Probably best to open a new bug if similar issue crops up.

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