Red Hat Bugzilla – Bug 187293
cpufreq sleeping whilst atomic during suspend/resume.
Last modified: 2007-12-10 17:03:11 EST
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
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):
Steps to Reproduce:
1. Stop cpuspeed service
2. modprobe cpufreq_ondemand
3. echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Blank screen, unresponsive to input (except limited sysrq)
Expected machine to fully wakeup and let me back into X
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.
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
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>]
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.