Bug 48341
| Summary: | BUG: using smp_processor_id in preemptible powernow_k8 | ||
|---|---|---|---|
| Product: | Power Management | Reporter: | Andy Furniss (lists) |
| Component: | cpufreq | Assignee: | Lan Tianyu (tianyu.lan) |
| Status: | CLOSED PATCH_ALREADY_AVAILABLE | ||
| Severity: | normal | CC: | aaron.lu, alan, hedi, herrmann.der.user, lenb, netsys, rui.zhang, tianyu.lan |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.6.0-rc7 (drm-core-next) | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: | dmesg | ||
With drm-fixes - 3.7.0-rc2-70305-g96fb1a2 I see - powernow-k8: this CPU is not supported anymore, using acpi-cpufreq instead. Which seems to be working Ok, so closing. Actually this should be solved by the following commit: e4df1cb: cpufreq / powernow-k8: Remove usage of smp_processor_id() in preemptible code Cheers, Hedi. Does not work on A6-4440M powernow-k8: this CPU is not supported anymore, using acpi-cpufreq instead. 3.7.2-204.fc18.x86_64 On Saturday, January 26, 2013 12:00:54 PM bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=48341 > --- Comment #3 from Álvaro Castillo <netsys@fedoraproject.org> 2013-01-26 > 12:00:53 --- > Does not work on A6-4440M > powernow-k8: this CPU is not supported anymore, using acpi-cpufreq instead. > > 3.7.2-204.fc18.x86_64 Can you please test the current mainline (v3.8-rc5 as of today)? A few patches have been applied to it affecting this area. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. (In reply to comment #3) > Does not work on A6-4440M > powernow-k8: this CPU is not supported anymore, using acpi-cpufreq instead. > > 3.7.2-204.fc18.x86_64 What's the problem? Did you get a call backtrace or cpufreq does not work for you? And if there is a problem, can you please test the current mainline as comment #4 has suggested? Thanks. Hi, If you get "powernow-k8: this CPU is not supported anymore, using acpi-cpufreq instead." on the latest kernel, this means the powernowk8_target() will not be registed and never be called. So the original bug should never take place. So close this bug. If it still existed, Please feel free reopen this bug.
Code from drivers/cpufreg/powernow-k8.c
static struct cpufreq_driver cpufreq_amd64_driver = {
.verify = powernowk8_verify,
.target = powernowk8_target,
....
};
static void __request_acpi_cpufreq(void)
{
...
pr_warn(PFX "This CPU is not supported anymore, using acpi-cpufreq instead.\n");
request_module(drv);
}
powernowk8_init(void)
{
if (static_cpu_has(X86_FEATURE_HW_PSTATE)) {
__request_acpi_cpufreq();
return -ENODEV;
}
...
ret = cpufreq_register_driver(&cpufreq_amd64_driver);
....
}
|
Created attachment 82111 [details] dmesg Since upgrading kernel(drm-core-next) from 3.6.0-rc2-57331-g269b62d to 3.6.0-rc7-59005-g2216c9e I am getting these with cpufreq BUG: using smp_processor_id() in preemptible [00000000] code: modprobe/222 caller is powernowk8_target+0x17/0x50 [powernow_k8] Pid: 222, comm: modprobe Not tainted 3.6.0-rc7-59005-g2216c9e #1 Call Trace: [<c0626ced>] debug_smp_processor_id+0xcd/0xd0 [<f82dda10>] ? powernowk8_target_fn+0x9b0/0x9b0 [powernow_k8] [<f82dda27>] powernowk8_target+0x17/0x50 [powernow_k8] [<c0748393>] __cpufreq_driver_target+0x63/0xa0 [<c04587d6>] ? srcu_notifier_chain_register+0x36/0x60 [<c074aafd>] cpufreq_governor_userspace+0x16d/0x2d0 [<c0812eed>] ? notifier_call_chain+0x2d/0x60 [<c07484c5>] __cpufreq_governor+0x55/0xd0 [<c07486f9>] __cpufreq_set_policy+0x179/0x240 [<c0565163>] ? sysfs_add_file+0x13/0x20 [<c0749dfe>] cpufreq_add_dev+0x66e/0x7b0 [<c0810372>] ? _raw_spin_unlock_irqrestore+0x12/0x30 [<c074a640>] ? cpufreq_update_policy+0x100/0x100 [<c06aa44d>] subsys_interface_register+0x7d/0xb0 [<f82dc640>] ? write_new_fid+0x140/0x140 [powernow_k8] [<c07494cc>] cpufreq_register_driver+0x9c/0x1d0 [<f82de64d>] powernowk8_init+0x16d/0x1cd [powernow_k8] [<f82de4e0>] ? powernowk8_cpu_init+0x8e0/0x8e0 [powernow_k8] [<c04011f3>] do_one_initcall+0x103/0x150 [<c04588da>] ? blocking_notifier_call_chain+0x1a/0x20 [<c048a577>] sys_init_module+0xc7/0x10a0 [<c062f000>] ? ddebug_dyndbg_param_cb+0x70/0x70 [<c0815d93>] sysenter_do_call+0x12/0x22 dmesg attached.