Messages in this thread | | | From | Johannes Weiner <> | Subject | Re: [BUG] While changing the cpufreq governor, kernel hits a bug in workqueue.c | Date | Tue, 12 Aug 2008 23:44:51 +0200 |
| |
Johannes Weiner <hannes@saeurebad.de> writes:
> Hi Nageswara, > > Nageswara R Sastry <rnsastry@linux.vnet.ibm.com> writes: > >> Any updates on this bug. > > Sorry. I was just looking into it again and still see no resolution. > Added Venkatesh and Alexey to CC.
Sorry, wrong address for Alexey. Hope this one works.
> To summarize again: > > The problem we have is that cpufreq_ondemand has a self-rearming worker > function which we should but can not cancel synchroneously with the > current code. The locking order is like this: > > store() > policy_rwsem write > cpufreq_governor_dbs() > dbs_mutex > > work lock > do_dbs_timer() > policy_rwsem write > > which gives a locking hierarchy of: > > work lock > policy_rwsem > dbs_mutex > > Now, we _should_ cancel the worker synchroneously, but that won't fly > since when cpufreq_governor_dbs() is called, we already hold > policy_rwsem and grabbing the work lock is illegal. > > I will continue to read code and see if I can come up with a solution, > but any help is really appreciated. > > I have not yet looked at cpufreq_conservative... > >> Thanks and Regards >> R.Nageswara Sastry > > Thanks for your patience and insistence, > > Hannes
| |