Bug 526006

Summary: Kernel update 2.6.30.5-43.fc11.x86_64 breaks cpufreq changing
Product: [Fedora] Fedora Reporter: Honza Ustohal <honza>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 11CC: dougsland, gansalmon, itamar, kernel-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-01 17:05:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Honza Ustohal 2009-09-28 09:49:33 UTC
Description of problem:
After update to kernel 2.6.30.5-43, 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):
kernel-2.6.30.5-43.fc11.x86_64
cpufrequtils-005-3.fc11.x86_64


How reproducible:


Steps to Reproduce:
1. Boot 2.6.30.5-43.fc11.x86_64 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 2.6.30.8-64, 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 2.6.30.8-64, please test and report back.  

Bug verified...fixed in 2.6.30.8-64,,,thanks