Bug 526006 - Kernel update breaks cpufreq changing
Summary: Kernel update breaks cpufreq changing
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 11
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-09-28 09:49 UTC by Honza Ustohal
Modified: 2009-10-01 17:05 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-10-01 17:05:03 UTC
Type: ---

Attachments (Terms of Use)

Description Honza Ustohal 2009-09-28 09:49:33 UTC
Description of problem:
After update to kernel, all components accessing CPU frequency settings (cpufreq-set, cpufreq-info, trayfreq) stopped working. It is not possible to select other governor than ondemand, which is loaded by default.
Invoking command like 'cpufreq-set -c 0 -g powersave' results in total lockup and after two minutes, dmesg shows message:

INFO: task cpufreq-set:1723 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
cpufreq-set   D 7fffffffffffffff     0  1723   1721
 ffff88007614d9e8 0000000000000082 7fffffffffffffff ffff880001022cc0
 000000007614d968 00000000476aa314 ffff88007614d998 ffffffff81051996
 ffff88007500c998 000000000000e2e8 ffff88007500c998 0000000000012cc0
Call Trace:
 [<ffffffff81051996>] ? finish_task_switch+0xc2/0xfb
 [<ffffffff81496557>] ? thread_return+0x4e/0xc4
 [<ffffffff814965ee>] schedule+0x21/0x49
 [<ffffffff81496ab7>] schedule_timeout+0x36/0xe1
 [<ffffffff81045d63>] ? __wake_up+0x53/0x70
 [<ffffffff81496832>] wait_for_common+0xd3/0x137
 [<ffffffff8104e4e6>] ? default_wake_function+0x0/0x3b
 [<ffffffff814969e8>] wait_for_completion+0x30/0x46
 [<ffffffff8106c013>] __cancel_work_timer+0x17f/0x1ea
 [<ffffffff8106bd09>] ? wq_barrier_func+0x0/0x3b
 [<ffffffff8106c0a3>] cancel_delayed_work_sync+0x25/0x3b
 [<ffffffffa032bce0>] cpufreq_governor_dbs+0x240/0x2c4 [cpufreq_ondemand]
 [<ffffffff813b08cb>] __cpufreq_governor+0xb6/0x10a
 [<ffffffff813b0b12>] __cpufreq_set_policy+0x197/0x241
 [<ffffffff813b170b>] store_scaling_governor+0x1a0/0x1e8
 [<ffffffff813b1ffb>] ? handle_update+0x0/0x5c
 [<ffffffff813b1e83>] store+0x6a/0xa3
 [<ffffffff81174d45>] sysfs_write_file+0x106/0x156
 [<ffffffff81114f6e>] vfs_write+0xbd/0x12e
 [<ffffffff81121882>] ? putname+0x45/0x62
 [<ffffffff811150d1>] sys_write+0x59/0x91
 [<ffffffff81012082>] system_call_fastpath+0x16/0x1b

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Boot kernel
2. try to change CPU governor to something else than ondemand
3. apllication, that invoked the change locks up
Actual results:
Application locks-up, governor is not changed

Expected results:
Changed governor

Additional info:

Comment 1 Chuck Ebbert 2009-09-30 06:04:06 UTC
This should be fixed in, please test and report back.

Comment 2 Honza Ustohal 2009-09-30 06:47:29 UTC
(In reply to comment #1)
> This should be fixed in, please test and report back.  

Bug verified...fixed in,,,thanks

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