* Another bad usage of smp_processor_id
@ 2010-08-29 10:26 Maxim Levitsky
2010-09-01 10:25 ` Maxim Levitsky
0 siblings, 1 reply; 6+ messages in thread
From: Maxim Levitsky @ 2010-08-29 10:26 UTC (permalink / raw)
To: linux-acpi@vger.kernel.org
Hi,
Now that I applied the patch that makes NMI watchdog not trigger this,
the amount of backtraces reduced, so I finally notice that on resume:
[ 3226.997285] Back to C!
[ 3226.997285] PM: Restoring platform NVS memory
[ 3226.997285] CPU0: Thermal monitoring handled by SMI
[ 3226.997285] Enabling non-boot CPUs ...
[ 3227.000076] BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/5185
[ 3227.000085] caller is thermal_throttle_add_dev+0x20/0xa4
[ 3227.000091] Pid: 5185, comm: pm-suspend Tainted: P 2.6.36-rc2+ #132
[ 3227.000096] Call Trace:
[ 3227.000104] [<ffffffff811e6242>] debug_smp_processor_id+0xd2/0xf0
[ 3227.000110] [<ffffffff813a0174>] thermal_throttle_add_dev+0x20/0xa4
[ 3227.000117] [<ffffffff813a0244>] thermal_throttle_cpu_callback+0x4c/0xb7
[ 3227.000123] [<ffffffff81063c61>] notifier_call_chain+0x51/0x80
[ 3227.000130] [<ffffffff810425d2>] ? cpu_maps_update_begin+0x12/0x20
[ 3227.000136] [<ffffffff81063d19>] __raw_notifier_call_chain+0x9/0x10
[ 3227.000141] [<ffffffff8104258b>] __cpu_notify+0x1b/0x30
[ 3227.000147] [<ffffffff813a29d4>] _cpu_up+0x6e/0x10d
[ 3227.000153] [<ffffffff81396335>] enable_nonboot_cpus+0x95/0xc0
[ 3227.000160] [<ffffffff8107ffcc>] suspend_devices_and_enter+0x10c/0x1e0
[ 3227.000166] [<ffffffff810801bc>] enter_state+0x11c/0x190
[ 3227.000172] [<ffffffff8107f821>] state_store+0x91/0x100
[ 3227.000179] [<ffffffff811d7a87>] kobj_attr_store+0x17/0x20
[ 3227.000185] [<ffffffff8114a392>] sysfs_write_file+0xf2/0x170
[ 3227.000192] [<ffffffff810df658>] vfs_write+0xc8/0x190
[ 3227.000198] [<ffffffff810df7ff>] sys_write+0x4f/0x90
[ 3227.000205] [<ffffffff81002deb>] system_call_fastpath+0x16/0x1b
[ 3227.000328] lockdep: fixing up alternatives.
[ 3227.000332] SMP alternatives: switching to SMP code
Best regards,
Maxim Levitsky
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Another bad usage of smp_processor_id
2010-08-29 10:26 Another bad usage of smp_processor_id Maxim Levitsky
@ 2010-09-01 10:25 ` Maxim Levitsky
2010-09-03 6:01 ` Zhang Rui
0 siblings, 1 reply; 6+ messages in thread
From: Maxim Levitsky @ 2010-09-01 10:25 UTC (permalink / raw)
To: linux-acpi@vger.kernel.org
On Sun, 2010-08-29 at 13:26 +0300, Maxim Levitsky wrote:
> Hi,
>
> Now that I applied the patch that makes NMI watchdog not trigger this,
> the amount of backtraces reduced, so I finally notice that on resume:
>
> [ 3226.997285] Back to C!
> [ 3226.997285] PM: Restoring platform NVS memory
> [ 3226.997285] CPU0: Thermal monitoring handled by SMI
> [ 3226.997285] Enabling non-boot CPUs ...
> [ 3227.000076] BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/5185
> [ 3227.000085] caller is thermal_throttle_add_dev+0x20/0xa4
> [ 3227.000091] Pid: 5185, comm: pm-suspend Tainted: P 2.6.36-rc2+ #132
> [ 3227.000096] Call Trace:
> [ 3227.000104] [<ffffffff811e6242>] debug_smp_processor_id+0xd2/0xf0
> [ 3227.000110] [<ffffffff813a0174>] thermal_throttle_add_dev+0x20/0xa4
> [ 3227.000117] [<ffffffff813a0244>] thermal_throttle_cpu_callback+0x4c/0xb7
> [ 3227.000123] [<ffffffff81063c61>] notifier_call_chain+0x51/0x80
> [ 3227.000130] [<ffffffff810425d2>] ? cpu_maps_update_begin+0x12/0x20
> [ 3227.000136] [<ffffffff81063d19>] __raw_notifier_call_chain+0x9/0x10
> [ 3227.000141] [<ffffffff8104258b>] __cpu_notify+0x1b/0x30
> [ 3227.000147] [<ffffffff813a29d4>] _cpu_up+0x6e/0x10d
> [ 3227.000153] [<ffffffff81396335>] enable_nonboot_cpus+0x95/0xc0
> [ 3227.000160] [<ffffffff8107ffcc>] suspend_devices_and_enter+0x10c/0x1e0
> [ 3227.000166] [<ffffffff810801bc>] enter_state+0x11c/0x190
> [ 3227.000172] [<ffffffff8107f821>] state_store+0x91/0x100
> [ 3227.000179] [<ffffffff811d7a87>] kobj_attr_store+0x17/0x20
> [ 3227.000185] [<ffffffff8114a392>] sysfs_write_file+0xf2/0x170
> [ 3227.000192] [<ffffffff810df658>] vfs_write+0xc8/0x190
> [ 3227.000198] [<ffffffff810df7ff>] sys_write+0x4f/0x90
> [ 3227.000205] [<ffffffff81002deb>] system_call_fastpath+0x16/0x1b
> [ 3227.000328] lockdep: fixing up alternatives.
> [ 3227.000332] SMP alternatives: switching to SMP code
>
> Best regards,
> Maxim Levitsky
>
ping
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Another bad usage of smp_processor_id
2010-09-01 10:25 ` Maxim Levitsky
@ 2010-09-03 6:01 ` Zhang Rui
2010-09-07 8:18 ` Maxim Levitsky
0 siblings, 1 reply; 6+ messages in thread
From: Zhang Rui @ 2010-09-03 6:01 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: linux-acpi@vger.kernel.org
Hi, Maxim,
please try this patch and see if the problem still exists. :)
On Wed, 2010-09-01 at 18:25 +0800, Maxim Levitsky wrote:
> On Sun, 2010-08-29 at 13:26 +0300, Maxim Levitsky wrote:
> > Hi,
> >
> > Now that I applied the patch that makes NMI watchdog not trigger this,
> > the amount of backtraces reduced, so I finally notice that on resume:
> >
> > [ 3226.997285] Back to C!
> > [ 3226.997285] PM: Restoring platform NVS memory
> > [ 3226.997285] CPU0: Thermal monitoring handled by SMI
> > [ 3226.997285] Enabling non-boot CPUs ...
> > [ 3227.000076] BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/5185
> > [ 3227.000085] caller is thermal_throttle_add_dev+0x20/0xa4
> > [ 3227.000091] Pid: 5185, comm: pm-suspend Tainted: P 2.6.36-rc2+ #132
> > [ 3227.000096] Call Trace:
> > [ 3227.000104] [<ffffffff811e6242>] debug_smp_processor_id+0xd2/0xf0
> > [ 3227.000110] [<ffffffff813a0174>] thermal_throttle_add_dev+0x20/0xa4
> > [ 3227.000117] [<ffffffff813a0244>] thermal_throttle_cpu_callback+0x4c/0xb7
> > [ 3227.000123] [<ffffffff81063c61>] notifier_call_chain+0x51/0x80
> > [ 3227.000130] [<ffffffff810425d2>] ? cpu_maps_update_begin+0x12/0x20
> > [ 3227.000136] [<ffffffff81063d19>] __raw_notifier_call_chain+0x9/0x10
> > [ 3227.000141] [<ffffffff8104258b>] __cpu_notify+0x1b/0x30
> > [ 3227.000147] [<ffffffff813a29d4>] _cpu_up+0x6e/0x10d
> > [ 3227.000153] [<ffffffff81396335>] enable_nonboot_cpus+0x95/0xc0
> > [ 3227.000160] [<ffffffff8107ffcc>] suspend_devices_and_enter+0x10c/0x1e0
> > [ 3227.000166] [<ffffffff810801bc>] enter_state+0x11c/0x190
> > [ 3227.000172] [<ffffffff8107f821>] state_store+0x91/0x100
> > [ 3227.000179] [<ffffffff811d7a87>] kobj_attr_store+0x17/0x20
> > [ 3227.000185] [<ffffffff8114a392>] sysfs_write_file+0xf2/0x170
> > [ 3227.000192] [<ffffffff810df658>] vfs_write+0xc8/0x190
> > [ 3227.000198] [<ffffffff810df7ff>] sys_write+0x4f/0x90
> > [ 3227.000205] [<ffffffff81002deb>] system_call_fastpath+0x16/0x1b
> > [ 3227.000328] lockdep: fixing up alternatives.
> > [ 3227.000332] SMP alternatives: switching to SMP code
> >
Don't use smp_processor_id() when preempt enabled.
Maxim got this on resume,
[ 3226.997285] Back to C!
[ 3226.997285] PM: Restoring platform NVS memory
[ 3226.997285] CPU0: Thermal monitoring handled by SMI
[ 3226.997285] Enabling non-boot CPUs ...
[ 3227.000076] BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/5185
[ 3227.000085] caller is thermal_throttle_add_dev+0x20/0xa4
[ 3227.000091] Pid: 5185, comm: pm-suspend Tainted: P 2.6.36-rc2+ #132
[ 3227.000096] Call Trace:
[ 3227.000104] [<ffffffff811e6242>] debug_smp_processor_id+0xd2/0xf0
[ 3227.000110] [<ffffffff813a0174>] thermal_throttle_add_dev+0x20/0xa4
[ 3227.000117] [<ffffffff813a0244>] thermal_throttle_cpu_callback+0x4c/0xb7
[ 3227.000123] [<ffffffff81063c61>] notifier_call_chain+0x51/0x80
[ 3227.000130] [<ffffffff810425d2>] ? cpu_maps_update_begin+0x12/0x20
[ 3227.000136] [<ffffffff81063d19>] __raw_notifier_call_chain+0x9/0x10
[ 3227.000141] [<ffffffff8104258b>] __cpu_notify+0x1b/0x30
[ 3227.000147] [<ffffffff813a29d4>] _cpu_up+0x6e/0x10d
[ 3227.000153] [<ffffffff81396335>] enable_nonboot_cpus+0x95/0xc0
[ 3227.000160] [<ffffffff8107ffcc>] suspend_devices_and_enter+0x10c/0x1e0
[ 3227.000166] [<ffffffff810801bc>] enter_state+0x11c/0x190
[ 3227.000172] [<ffffffff8107f821>] state_store+0x91/0x100
[ 3227.000179] [<ffffffff811d7a87>] kobj_attr_store+0x17/0x20
[ 3227.000185] [<ffffffff8114a392>] sysfs_write_file+0xf2/0x170
[ 3227.000192] [<ffffffff810df658>] vfs_write+0xc8/0x190
[ 3227.000198] [<ffffffff810df7ff>] sys_write+0x4f/0x90
[ 3227.000205] [<ffffffff81002deb>] system_call_fastpath+0x16/0x1b
[ 3227.000328] lockdep: fixing up alternatives.
[ 3227.000332] SMP alternatives: switching to SMP code
Reported-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
---
arch/x86/kernel/cpu/mcheck/therm_throt.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
Index: linux-2.6/arch/x86/kernel/cpu/mcheck/therm_throt.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/mcheck/therm_throt.c 2010-09-03 10:43:29.000000000 +0800
+++ linux-2.6/arch/x86/kernel/cpu/mcheck/therm_throt.c 2010-09-03 13:38:45.000000000 +0800
@@ -202,14 +202,16 @@
#ifdef CONFIG_SYSFS
/* Add/Remove thermal_throttle interface for CPU device: */
-static __cpuinit int thermal_throttle_add_dev(struct sys_device *sys_dev)
+static __cpuinit int thermal_throttle_add_dev(unsigned int cpu)
{
int err;
- struct cpuinfo_x86 *c = &cpu_data(smp_processor_id());
+ struct sys_device *sys_dev;
+ struct cpuinfo_x86 *c = &cpu_data(cpu);
+ sys_dev=get_cpu_sysdev(cpu);
err = sysfs_create_group(&sys_dev->kobj, &thermal_attr_group);
if (err)
- return err;
+ goto end;
if (cpu_has(c, X86_FEATURE_PLN))
err = sysfs_add_file_to_group(&sys_dev->kobj,
@@ -224,11 +226,14 @@
&attr_package_power_limit_count.attr,
thermal_attr_group.name);
+end:
+ put_cpu();
return err;
}
-static __cpuinit void thermal_throttle_remove_dev(struct sys_device *sys_dev)
+static __cpuinit void thermal_throttle_remove_dev(unsigned int cpu)
{
+ struct sys_device *sys_dev=get_cpu_sysdev(cpu);
sysfs_remove_group(&sys_dev->kobj, &thermal_attr_group);
}
@@ -242,16 +247,13 @@
void *hcpu)
{
unsigned int cpu = (unsigned long)hcpu;
- struct sys_device *sys_dev;
int err = 0;
- sys_dev = get_cpu_sysdev(cpu);
-
switch (action) {
case CPU_UP_PREPARE:
case CPU_UP_PREPARE_FROZEN:
mutex_lock(&therm_cpu_lock);
- err = thermal_throttle_add_dev(sys_dev);
+ err = thermal_throttle_add_dev(cpu);
mutex_unlock(&therm_cpu_lock);
WARN_ON(err);
break;
@@ -260,7 +262,7 @@
case CPU_DEAD:
case CPU_DEAD_FROZEN:
mutex_lock(&therm_cpu_lock);
- thermal_throttle_remove_dev(sys_dev);
+ thermal_throttle_remove_dev(cpu);
mutex_unlock(&therm_cpu_lock);
break;
}
@@ -287,7 +289,7 @@
#endif
/* connect live CPUs to sysfs */
for_each_online_cpu(cpu) {
- err = thermal_throttle_add_dev(get_cpu_sysdev(cpu));
+ err = thermal_throttle_add_dev(cpu);
WARN_ON(err);
}
#ifdef CONFIG_HOTPLUG_CPU
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Another bad usage of smp_processor_id
2010-09-03 6:01 ` Zhang Rui
@ 2010-09-07 8:18 ` Maxim Levitsky
2010-09-12 9:37 ` Maxim Levitsky
0 siblings, 1 reply; 6+ messages in thread
From: Maxim Levitsky @ 2010-09-07 8:18 UTC (permalink / raw)
To: Zhang Rui; +Cc: linux-acpi@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 225 bytes --]
On Fri, 2010-09-03 at 14:01 +0800, Zhang Rui wrote:
> Hi, Maxim,
>
> please try this patch and see if the problem still exists. :)
Yes it does :)
And its worse since my system now panics on resume...
Kernel log attached.
[-- Attachment #2: old_dmesg.tar.bz2 --]
[-- Type: application/x-bzip-compressed-tar, Size: 56256 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Another bad usage of smp_processor_id
2010-09-07 8:18 ` Maxim Levitsky
@ 2010-09-12 9:37 ` Maxim Levitsky
2010-09-14 23:14 ` Maxim Levitsky
0 siblings, 1 reply; 6+ messages in thread
From: Maxim Levitsky @ 2010-09-12 9:37 UTC (permalink / raw)
To: Zhang Rui; +Cc: linux-acpi@vger.kernel.org
On Tue, 2010-09-07 at 11:18 +0300, Maxim Levitsky wrote:
> On Fri, 2010-09-03 at 14:01 +0800, Zhang Rui wrote:
> > Hi, Maxim,
> >
> > please try this patch and see if the problem still exists. :)
> Yes it does :)
> And its worse since my system now panics on resume...
> Kernel log attached.
Ping.
Best regards,
Maxim Levitsky
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Another bad usage of smp_processor_id
2010-09-12 9:37 ` Maxim Levitsky
@ 2010-09-14 23:14 ` Maxim Levitsky
0 siblings, 0 replies; 6+ messages in thread
From: Maxim Levitsky @ 2010-09-14 23:14 UTC (permalink / raw)
To: Zhang Rui; +Cc: linux-acpi@vger.kernel.org
On Sun, 2010-09-12 at 11:37 +0200, Maxim Levitsky wrote:
> On Tue, 2010-09-07 at 11:18 +0300, Maxim Levitsky wrote:
> > On Fri, 2010-09-03 at 14:01 +0800, Zhang Rui wrote:
> > > Hi, Maxim,
> > >
> > > please try this patch and see if the problem still exists. :)
> > Yes it does :)
> > And its worse since my system now panics on resume...
> > Kernel log attached.
Ok. 2.6.36-rc4 fixes this.
Best regards,
Maxim Levitsky
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-09-14 23:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-08-29 10:26 Another bad usage of smp_processor_id Maxim Levitsky
2010-09-01 10:25 ` Maxim Levitsky
2010-09-03 6:01 ` Zhang Rui
2010-09-07 8:18 ` Maxim Levitsky
2010-09-12 9:37 ` Maxim Levitsky
2010-09-14 23:14 ` Maxim Levitsky
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox