here is the output : Pid: 1692, comm: cpufreq-set Not tainted 2.6.35-rc2-radeon-00001-g386f40c #1 Call Trace: [<ffffffff811f8772>] debug_smp_processor_id+0xd2/0xf0 [<ffffffff810324b5>] nr_iowait_cpu+0x15/0x30 [<ffffffff810717ba>] update_ts_time_stats+0x6a/0x90 [<ffffffff8106c5db>] ? ktime_get+0x5b/0xe0 [<ffffffff8107199d>] get_cpu_idle_time_us+0x4d/0x70 [<ffffffff813ec3d8>] cpufreq_governor_dbs+0x1e8/0x440 [<ffffffff813e87ed>] __cpufreq_governor+0xdd/0x1d0 [<ffffffff813e931d>] ? lock_policy_rwsem_write+0x4d/0x90 [<ffffffff813e991f>] __cpufreq_set_policy+0x1cf/0x250 [<ffffffff813e9d4d>] store_scaling_governor+0xbd/0x1f0 [<ffffffff813ea720>] ? handle_update+0x0/0x40 [<ffffffff814ad200>] ? _raw_read_unlock+0x0/0x40 [<ffffffff813e9722>] store+0x62/0x90 [<ffffffff81149fe0>] sysfs_write_file+0xe0/0x160 [<ffffffff810e9f40>] vfs_write+0xb0/0x170 [<ffffffff810ea0dc>] sys_write+0x4c/0x80 [<ffffffff8100242b>] system_call_fastpath+0x16/0x1b caller is nr_iowait_cpu+0x15/0x30 Pid: 1693, comm: cpufreq-set Not tainted 2.6.35-rc2-radeon-00001-g386f40c #1 Call Trace: [<ffffffff811f8772>] debug_smp_processor_id+0xd2/0xf0 [<ffffffff810324b5>] nr_iowait_cpu+0x15/0x30 [<ffffffff810717ba>] update_ts_time_stats+0x6a/0x90 [<ffffffff8106c5db>] ? ktime_get+0x5b/0xe0 [<ffffffff8107199d>] get_cpu_idle_time_us+0x4d/0x70 [<ffffffff813ec3d8>] cpufreq_governor_dbs+0x1e8/0x440 [<ffffffff813e87ed>] __cpufreq_governor+0xdd/0x1d0 [<ffffffff813e931d>] ? lock_policy_rwsem_write+0x4d/0x90 [<ffffffff813e991f>] __cpufreq_set_policy+0x1cf/0x250 [<ffffffff813e9d4d>] store_scaling_governor+0xbd/0x1f0 [<ffffffff813ea720>] ? handle_update+0x0/0x40 [<ffffffff814ad200>] ? _raw_read_unlock+0x0/0x40 [<ffffffff813e9722>] store+0x62/0x90 [<ffffffff81149fe0>] sysfs_write_file+0xe0/0x160 [<ffffffff810e9f40>] vfs_write+0xb0/0x170 [<ffffffff810ea0dc>] sys_write+0x4c/0x80 [<ffffffff8100242b>] system_call_fastpath+0x16/0x1b caller is nr_iowait_cpu+0x15/0x30 Pid: 1694, comm: cpufreq-set Not tainted 2.6.35-rc2-radeon-00001-g386f40c #1 Call Trace: [<ffffffff811f8772>] debug_smp_processor_id+0xd2/0xf0 [<ffffffff810324b5>] nr_iowait_cpu+0x15/0x30 [<ffffffff810717ba>] update_ts_time_stats+0x6a/0x90 [<ffffffff8106c5db>] ? ktime_get+0x5b/0xe0 [<ffffffff8107199d>] get_cpu_idle_time_us+0x4d/0x70 [<ffffffff813ec3d8>] cpufreq_governor_dbs+0x1e8/0x440 [<ffffffff813e87ed>] __cpufreq_governor+0xdd/0x1d0 [<ffffffff813e931d>] ? lock_policy_rwsem_write+0x4d/0x90 [<ffffffff813e991f>] __cpufreq_set_policy+0x1cf/0x250 [<ffffffff813e9d4d>] store_scaling_governor+0xbd/0x1f0 [<ffffffff813ea720>] ? handle_update+0x0/0x40 [<ffffffff814ad200>] ? _raw_read_unlock+0x0/0x40 [<ffffffff813e9722>] store+0x62/0x90 [<ffffffff81149fe0>] sysfs_write_file+0xe0/0x160 [<ffffffff810e9f40>] vfs_write+0xb0/0x170 [<ffffffff810ea0dc>] sys_write+0x4c/0x80 [<ffffffff8100242b>] system_call_fastpath+0x16/0x1b
Created attachment 26720 [details] cpufreq-related patch I am trying this patch from https://patchwork.kernel.org/patch/103225/raw
It worked.
this patch is not upstream
DaveJ- what's up with this?
Please verify that the problem is still present in v3.8 and report back.
Hi Andrew, Did you try v3.8(or better, Linus' git tree)? And is the problem still there? Thanks.
This bug should have been resolved by commit 8c215bd3. Related link https://lkml.org/lkml/2010/6/16/389 https://lkml.org/lkml/2010/6/17/23 commit 8c215bd3890c347dfb6a2db4779755f8b9c298a9 Author: Peter Zijlstra <peterz@infradead.org> Date: Thu Jul 1 09:07:17 2010 +0200 sched: Cure nr_iowait_cpu() users Commit 0224cf4c5e (sched: Intoduce get_cpu_iowait_time_us()) broke things by not making sure preemption was indeed disabled by the callers of nr_iowait_cpu() which took the iowait value of the current cpu. This resulted in a heap of preempt warnings. Cure this by making nr_iowait_cpu() take a cpu number and fix up the callers to pass in the right number.