Messages in this thread | | | Date | Mon, 13 Oct 2014 07:52:10 -0400 | From | Prarit Bhargava <> | Subject | Re: [PATCH] cpufreq, store_scaling_governor requires policy->rwsem to be held for duration of changing governors [v2] |
| |
On 10/13/2014 06:43 AM, Viresh Kumar wrote: > On 1 August 2014 22:48, Stephen Boyd <sboyd@codeaurora.org> wrote: >> On 08/01/14 03:27, Prarit Bhargava wrote: >>> >>> Can you send me the test and the trace of the deadlock? I'm not creating it with: >>> >> >> This was with conservative as the default, and switching to ondemand >> >> # cd /sys/devices/system/cpu/cpu2/cpufreq >> # ls >> affected_cpus scaling_available_governors >> conservative scaling_cur_freq >> cpuinfo_cur_freq scaling_driver >> cpuinfo_max_freq scaling_governor >> cpuinfo_min_freq scaling_max_freq >> cpuinfo_transition_latency scaling_min_freq >> related_cpus scaling_setspeed >> scaling_available_frequencies stats >> # cat conservative/down_threshold >> 20 >> # echo ondemand > scaling_governor >> >> ====================================================== >> [ INFO: possible circular locking dependency detected ] >> 3.16.0-rc3-00039-ge1e38f124d87 #47 Not tainted >> ------------------------------------------------------- >> sh/75 is trying to acquire lock: >> (s_active#9){++++..}, at: [<c0358a94>] kernfs_remove_by_name_ns+0x3c/0x84 > > Can you please retry this on mainline? I wasn't able to reproduce it > now over 3.17. > I am trying this on Exynos b.L implementation..
I have 100% reproducibility on latest mainline.
Viresh, please see my next post on the locking issues in cpufreq.
P.
>
| |