lkml.org 
[lkml]   [2013]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
SubjectRe: NOHZ: WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule, round 2
From
On 20 May 2013 15:10, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 20 May 2013 15:01, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote:
>> And Viresh, in the regular hotplug paths, the call to gov_cancel_work() is
>> supposed to kill any pending workqueue functions pertaining to offline CPUs
>> right?
>
> Yes.. It will cancel work for all cpus first and will start again for
> online cpus again.
>
>> Could there be a synchronization bug somewhere due to which this
>> might not be happening properly?
>
> Not sure.. I have seen mutex's are used well in cpufreq_governor.. don't know
> if I missed something.

Borislav,

Can you try below change to see if the issue is still present? (Untested)

diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index 7532570..b9ae5f6 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -359,7 +359,9 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
if (dbs_data->cdata->governor == GOV_CONSERVATIVE)
cs_dbs_info->enable = 0;

+ mutex_lock(&cpu_cdbs->timer_mutex);
gov_cancel_work(dbs_data, policy);
+ mutex_unlock(&cpu_cdbs->timer_mutex);

mutex_lock(&dbs_data->mutex);
mutex_destroy(&cpu_cdbs->timer_mutex);

\
 
 \ /
  Last update: 2013-05-20 13:21    [W:0.058 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site