Description of problem: The 2.6.16 kernel is the first to have the ability to use the ich-speedstep module and ondemand with my machine. However on suspend and resume when using this driver, it fails to resume. The Sysrq buttons still work (as far as sync and remount, but not then reboot) also, when playing music with banshee, it carried on playing until the end of the file. However, my screen did not come back on, nor does any keyboard input (other than sysrq) seem to have any effect. The previous 2.6.15 kernel works fine (but no ondemand governor) and this kernel works providing I do not use the ondemand governor (it can be loaded however). Version-Release number of selected component (if applicable): kernel-2.6.16-1.2080_FC5 How reproducible: always Steps to Reproduce: 1. Stop cpuspeed service 2. modprobe cpufreq_ondemand 3. echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 4. Suspend 5. Resume Actual results: Blank screen, unresponsive to input (except limited sysrq) Expected results: Expected machine to fully wakeup and let me back into X Additional info:
Created attachment 127017 [details] Output of lspci
As a workaround I've creates a /etc/pm/hooks/01ondemand script which switches to the performance governor on suspend and a /etc/pm/hooks/99ondemand script which switches back to the ondemand governor on resume.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
Try with this kernel version results in the following stack trace to be generated on resume. This doesn't happen every time, but more often than not. Oct 17 09:34:59 echo kernel: Stopping tasks: ===================================================================================================| Oct 17 09:34:59 echo kernel: eth1: Going into suspend... Oct 17 09:34:59 echo kernel: NVRM: RmPowerManagement: 3 Oct 17 09:34:59 echo kernel: Intel machine check architecture supported. Oct 17 09:34:59 echo kernel: Intel machine check reporting enabled on CPU#0. Oct 17 09:34:59 echo kernel: CPU0: Intel P4/Xeon Extended MCE MSRs (12) available Oct 17 09:34:59 echo kernel: BUG: sleeping function called from invalid context at kernel/rwsem.c:20 Oct 17 09:34:59 echo kernel: in_atomic():0, irqs_disabled():1 Oct 17 09:34:59 echo kernel: [<c0403f10>] dump_trace+0x69/0x1af Oct 17 09:34:59 echo kernel: [<c040406e>] show_trace_log_lvl+0x18/0x2c Oct 17 09:34:59 echo kernel: [<c04045e9>] show_trace+0xf/0x11 Oct 17 09:34:59 echo kernel: [<c0404673>] dump_stack+0x15/0x17 Oct 17 09:34:59 echo kernel: [<c042ef78>] down_read+0x12/0x1f Oct 17 09:34:59 echo kernel: [<c0427923>] blocking_notifier_call_chain+0xe/0x29Oct 17 09:34:59 echo kernel: [<c05970df>] cpufreq_resume+0x118/0x13f Oct 17 09:34:59 echo kernel: [<c053f3d4>] __sysdev_resume+0x20/0x53 Oct 17 09:34:59 echo kernel: [<c053f515>] sysdev_resume+0x16/0x47 Oct 17 09:34:59 echo kernel: [<c05435a1>] device_power_up+0x5/0xa Oct 17 09:34:59 echo kernel: [<c0436861>] suspend_enter+0x3b/0x44 Oct 17 09:34:59 echo kernel: [<c0436997>] enter_state+0x12d/0x14f Oct 17 09:34:59 echo kernel: [<c0436a3e>] state_store+0x85/0x99 Oct 17 09:34:59 echo kernel: [<c04969ea>] subsys_attr_store+0x1e/0x22 Oct 17 09:34:59 echo kernel: [<c0496adc>] sysfs_write_file+0xa6/0xcc Oct 17 09:34:59 echo kernel: [<c0461292>] vfs_write+0xa8/0x159 Oct 17 09:34:59 echo kernel: [<c04617d8>] sys_write+0x41/0x67 Oct 17 09:34:59 echo kernel: [<c0402d9b>] syscall_call+0x7/0xb Oct 17 09:34:59 echo kernel: DWARF2 unwinder stuck at syscall_call+0x7/0xb Oct 17 09:34:59 echo kernel: Leftover inexact backtrace: Oct 17 09:34:59 echo kernel: =======================
I actually get tihs backtrace even with my ondemand hook scripts to switch governor during suspend/resume.
I've done some further testing where I never even load the ondemand governor, I still get the same stacktrace. So it does appear that ondemand is now working as expected.
This stack trace should be gone with newer kernel versions. Given what you wrote in the previous comment, I'll close this bug.