Bug 16168 - BUG: using smp_processor_id() in preemptible [00000000] code:
Summary: BUG: using smp_processor_id() in preemptible [00000000] code:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Power Management
Classification: Unclassified
Component: cpufreq (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: cpufreq
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-09 06:57 UTC by Sean Finney
Modified: 2012-01-18 02:12 UTC (History)
2 users (show)

See Also:
Kernel Version: v2.6.35-rc2-54-g84f7586
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description Sean Finney 2010-06-09 06:57:14 UTC
Note: this might be the same as Bug#16154, I wasn't entirely sure so I'm filing a seperate report but mentioning it just in case.

After pulling linux-2.6 this morning to get the fix for an unrelated bug, i see the following in dmesg:

[   19.951747] powernow-k8: Found 1 AMD Phenom(tm) II X3 720 Processor (3 cpu cores) (version 2.20.00)
[   19.951784] powernow-k8:    0 : pstate 0 (2800 MHz)
[   19.951786] powernow-k8:    1 : pstate 1 (2100 MHz)
[   19.951788] powernow-k8:    2 : pstate 2 (1600 MHz)
[   19.951789] powernow-k8:    3 : pstate 3 (800 MHz)
[   19.951815] BUG: using smp_processor_id() in preemptible [00000000] code: modprobe/2028
[   19.951819] caller is nr_iowait_cpu+0xd/0x21
[   19.951822] Pid: 2028, comm: modprobe Not tainted 2.6.35-rc2+ #2
[   19.951824] Call Trace:
[   19.951829]  [<ffffffff8116d94e>] ? debug_smp_processor_id+0xbe/0xd4
[   19.951832]  [<ffffffff81034711>] ? nr_iowait_cpu+0xd/0x21
[   19.951835]  [<ffffffff810689d8>] ? update_ts_time_stats+0x32/0x6b
[   19.951839]  [<ffffffff8100f6da>] ? read_tsc+0x5/0x16
[   19.951842]  [<ffffffff81064396>] ? ktime_get+0x5f/0xb8
[   19.951845]  [<ffffffff81068b82>] ? get_cpu_idle_time_us+0x3f/0x5c
[   19.951848]  [<ffffffff8120f3bc>] ? get_cpu_idle_time+0x18/0x9c
[   19.951851]  [<ffffffff8103ab70>] ? add_preempt_count+0x9e/0xa0
[   19.951854]  [<ffffffff8120ff34>] ? cpufreq_governor_dbs+0xc0/0x308
[   19.951857]  [<ffffffff8120d819>] ? __cpufreq_governor+0x59/0x91
[   19.951860]  [<ffffffff8120e7ff>] ? __cpufreq_set_policy+0x111/0x14e
[   19.951863]  [<ffffffff8120ea73>] ? cpufreq_add_dev_interface+0x237/0x251
[   19.951867]  [<ffffffffa0276e8d>] ? powernowk8_cpu_init_on_cpu+0x0/0x95 [powernow_k8]
[   19.951870]  [<ffffffff8103991b>] ? get_parent_ip+0x9/0x1b
[   19.951873]  [<ffffffff8120edfa>] ? handle_update+0x0/0xd
[   19.951877]  [<ffffffff81060a46>] ? __blocking_notifier_call_chain+0x58/0x63
[   19.951880]  [<ffffffff8120f374>] ? cpufreq_add_dev+0x3fd/0x40d
[   19.951883]  [<ffffffff811f4f7b>] ? sysdev_driver_register+0xb1/0x10b
[   19.951885]  [<ffffffff8120dd82>] ? cpufreq_register_driver+0x8c/0x133
[   19.951889]  [<ffffffffa0277084>] ? powernowk8_init+0x162/0x16d [powernow_k8]
[   19.951893]  [<ffffffffa0276f22>] ? powernowk8_init+0x0/0x16d [powernow_k8]
[   19.951896]  [<ffffffff81002064>] ? do_one_initcall+0x63/0x175
[   19.951899]  [<ffffffff81072ba9>] ? sys_init_module+0x97/0x1d6
[   19.951901]  [<ffffffff81008a42>] ? system_call_fastpath+0x16/0x1b
Comment 1 Len Brown 2011-01-18 06:16:21 UTC
I assume this was not an issue with 2.6.34.
did it go away before 2.6.35, or is it still a problem?
Comment 2 Zhang Rui 2012-01-18 02:12:06 UTC
Bug closed as there is no response from the bug reporter.
Please feel free to reopen it if the problem still exists in the latest upstream kernel.

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