[+ Tero] On Tue, Dec 16, 2014 at 8:07 PM, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > On 17 December 2014 at 02:33, Nishanth Menon <nm@xxxxxx> wrote: >> http://storage.armcloud.us/kernel-ci/next/next-20141216/arm-multi_v7_defconfig/lab-khilman/boot-omap5-uevm.html >> [ 2.071996] ------------[ cut here ]------------ >> [ 2.076831] kernel BUG at ../drivers/cpufreq/cpufreq.c:1258! >> [ 2.082753] Internal error: Oops - BUG: 0 [#1] SMP ARM > [...] > So the SoC was running on unlisted frequency and when we tried to > change to some other valid (listed) frequency, we failed. > > The comment over it describes why it is a BUG.. Its some SoC issue > and need to be resolved by somebody with a board. > > So, in short __cpufreq_driver_target() failed to change freq.. So this looks like a bug that has been hiding, but just exposed because cpufreq-cpu0 (now cpufreq-dt) was not getting built-in since before v3.18. On omap4-panda-es, v3.18 with multi_v7_defconfig + CPUFREQ_DT enabled, I see this: [ 2.062103] cpufreq: __cpufreq_add_dev: CPU0: Running at unlisted freq: 699977 KHz [ 2.070404] cpufreq: __cpufreq_add_dev: CPU0: Unlisted initial frequency changed to: 700000 KHz No BUG. But, in next-20141216, [ 2.083953] cpufreq: __cpufreq_add_dev: CPU0: Running at unlisted freq: 699977 KHz [ 2.091949] cpu cpu0: failed to set clock rate: -22 [ 2.097045] cpufreq: __target_index: Failed to change cpu frequency: -22 And then the BUG. So the BUG() itself isn't the problem with this regression. There's been a fair amount of changes in the OMAP clk driver (including some other regressions), so I suspect the culprit to be lying somewhere in the recent OMAP clock changes. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
