"Jon Medhurst (Tixy)" tixy@linaro.org writes:
On Tue, 2015-07-28 at 12:11 +0100, Jon Medhurst (Tixy) wrote:
On Tue, 2015-07-28 at 15:45 +0530, Amit Pundir wrote:
Hi Tixy,
On 27 July 2015 at 23:34, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Hi
With an ARM Landing Team branch based on LSK 3.18 Android I'm seeing a hang if I
echo 0 > /sys/devices/system/cpu/cpu1/online
After bisecting, I fixed this problem by reverting commit 553b785b5383 ("cpufreq: Iterate over all the possible cpus to create powerstats.")
So in this patch I believe instead of "for_each_possible_cpu" we should use "for_each_online_cpu". Can you please re-enable this patch and try this change?
That gets rid of the hang,
So does using your linaro-android [1] branch that isn't in LSK yet. The specific patch that fixes things is Kevin's "cpufreq_stats: fix use of cpufreq_for_each_valid_entry() iterator"
[1] git://android.git.linaro.org/kernel/linaro-android linaro-android-3.18-lsk
Right, without my fix (which Google has now merged into upstream AOSP), that branch doesn't even boot on some platforms. :/
but it somewhat defeats the purpose of the original patch doesn't it? Though that patch itself looks a bit suspect as the module init function already calls cpufreq_powerstats_create for each online cpu (via cpufreq_stats_create_table).
But I'm wrong because that init code probably won't get called, as the early return and comment in cpufreq_stats_create_table implies.
Anyway, I don't fancy opening this can of worms further. Google seems to have lots of patches in this area
I rather foolishly looked a little further and I spotted and bug in cpufreq_powerstats_create. That code is scanning device-tree for some 'current' bindings they invented, but the code doing the scanning erroneously assumes that Linux's cpu number relates to what's in device-tree, it doesn't. I.e. this is flawed...
snprintf(device_path, sizeof(device_path), "/cpus/cpu@%d", cpu); cpu_node = of_find_node_by_path(device_path);
Doesn't matter for us though, as we don't have Google's binding additions. Which means that this whole area of code is going to somewhat futilely keep allocating memory, scanning device-tree, failing, then cleaning up.
I too am quite unimpressed (and rather scared) of the haphazard hacking Google has been doing in the cpufreq drivers.
Kevin