On 09:37-20141217, Viresh Kumar 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 > > This is what we have hit: > > if ((cpufreq_driver->flags & CPUFREQ_NEED_INITIAL_FREQ_CHECK) > && has_target()) { > /* Are we running at unknown frequency ? */ > ret = cpufreq_frequency_table_get_index(policy, policy->cur); > if (ret == -EINVAL) { > /* Warn user and fix it */ > pr_warn("%s: CPU%d: Running at unlisted freq: %u KHz\n", > __func__, policy->cpu, policy->cur); > ret = __cpufreq_driver_target(policy, policy->cur - 1, > CPUFREQ_RELATION_L); > > /* > * Reaching here after boot in a few seconds may not > * mean that system will remain stable at "unknown" > * frequency for longer duration. Hence, a BUG_ON(). > */ > BUG_ON(ret); /********* We have hit > this one *******/ > pr_warn("%s: CPU%d: Unlisted initial frequency > changed to: %u KHz\n", > __func__, policy->cpu, policy->cur); > } > } > > > 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.. I still do not see the need to crash the entire system - OK, fine cpufreq is broke, but the remaining part of the system can easily function. That BUG does look like a ugly point and lack of proper cleanup logic - cpufreq should be expected to report and gracefully shut itself down, not screw up my platform boot. For that matter we have had cpufreq working on TI platforms for years now. I will eventually find time to track the issue down if no one else beats me to it, but it kinda indicates that things are probably starting to bitrot... -- Regards, Nishanth Menon -- 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
