Hi. Yesterday, on a freshly-compiled 2.6.30.5 kernel, I noticed that changing to a governor that exists as a module but is not loaded causes the process that did the change to go to state D, along with any process later accessing the cpufreq nodes. The CPU is a Thurion64, working with powernow-k8. The kernel is configured with CONFIG_X86_64, CONFIG_PREEMPT, CONFIG_NO_HZ. The governor, at the time the problem happened, was ondemand. The problem happened either when loading powersave or userspace. On the other hand, selecting a governor that is already loaded works fine, and trying to autoload a governor that does not exist fails normally. I do not have a lot of time to investigate, I hope this bug report may be useful. Regards, -- Nicolas George [34560.087058] INFO: task kondemand/0:5412 blocked for more than 120 seconds. [34560.087066] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [34560.087073] kondemand/0 D 0000000000000000 0 5412 2 [34560.087084] ffffffff80586380 0000000000000046 0000000000000001 ffff88003c9fed30 [34560.087094] ffff88003c9fefd8 ffff88003c9fefd8 ffffffff80596700 ffffffff80596f20 [34560.087104] ffff88003f853a00 ffff88003c9fed30 ffffffff805cbec0 ffffffffa02f1b00 [34560.087113] Call Trace: [34560.087150] [<ffffffffa02f0590>] ? do_dbs_timer+0x0/0x320 [cpufreq_ondemand] [34560.087162] [<ffffffff804ad553>] ? schedule+0x13/0x40 [34560.087172] [<ffffffff804afa35>] ? __down_write_nested+0x85/0xe0 [34560.087186] [<ffffffff8040dab8>] ? lock_policy_rwsem_write+0x18/0x40 [34560.087199] [<ffffffffa02f05ff>] ? do_dbs_timer+0x6f/0x320 [cpufreq_ondemand] [34560.087215] [<ffffffffa02f0590>] ? do_dbs_timer+0x0/0x320 [cpufreq_ondemand] [34560.087226] [<ffffffff8024a8ac>] ? worker_thread+0x19c/0x2c0 [34560.087234] [<ffffffff8024eb50>] ? autoremove_wake_function+0x0/0x30 [34560.087243] [<ffffffff8024a710>] ? worker_thread+0x0/0x2c0 [34560.087251] [<ffffffff8024a710>] ? worker_thread+0x0/0x2c0 [34560.087259] [<ffffffff8024e5ae>] ? kthread+0x4e/0x90 [34560.087267] [<ffffffff8020cb6a>] ? child_rip+0xa/0x20 [34560.087275] [<ffffffff8024e560>] ? kthread+0x0/0x90 [34560.087282] [<ffffffff8020cb60>] ? child_rip+0x0/0x20 [34560.087310] INFO: task cpufreq-set:25132 blocked for more than 120 seconds. [34560.087315] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [34560.087320] cpufreq-set D 0000000000000000 0 25132 1 [34560.087329] ffff880030d8c110 0000000000000082 0000000000000092 ffff88003d014d70 [34560.087338] ffff88003d015018 ffff88003d015018 ffff88003e467e48 7fffffffffffffff [34560.087348] ffff88003e467bb8 7fffffffffffffff 7fffffffffffffff 0000000000000000 [34560.087357] Call Trace: [34560.087367] [<ffffffff804ad553>] ? schedule+0x13/0x40 [34560.087376] [<ffffffff804adbd5>] ? schedule_timeout+0x175/0x1c0 [34560.087385] [<ffffffff80249d6d>] ? call_usermodehelper_exec+0x8d/0xd0 [34560.087394] [<ffffffff804ad95a>] ? wait_for_common+0x15a/0x1a0 [34560.087404] [<ffffffff80230190>] ? default_wake_function+0x0/0x10 [34560.087413] [<ffffffff80232884>] ? __wake_up+0x54/0xb0 [34560.087425] [<ffffffff8024adca>] ? __cancel_work_timer+0x16a/0x1d0 [34560.087434] [<ffffffff8024a520>] ? wq_barrier_func+0x0/0x10 [34560.087448] [<ffffffffa02f0951>] ? cpufreq_governor_dbs+0xa1/0x2bc [cpufreq_ondemand] [34560.087458] [<ffffffff8040c8c9>] ? __cpufreq_governor+0xc9/0x130 [34560.087468] [<ffffffff8040ca52>] ? __cpufreq_set_policy+0x122/0x180 [34560.087477] [<ffffffff8040d6ef>] ? store_scaling_governor+0xff/0x280 [34560.087486] [<ffffffff8040e1a0>] ? handle_update+0x0/0x10 [34560.087498] [<ffffffff8040e07b>] ? store+0x6b/0xa0 [34560.087507] [<ffffffff80302f3e>] ? sysfs_write_file+0xce/0x160 [34560.087517] [<ffffffff802ac9b9>] ? vfs_write+0xc9/0x170 [34560.087526] [<ffffffff802acb63>] ? sys_write+0x53/0xa0 [34560.087534] [<ffffffff8020bd68>] ? system_call_fastpath+0x16/0x1b
Attachment:
signature.asc
Description: Digital signature
