Re: Fwd: next boot: 101 boots: 89 pass, 12 fail (next-20141216)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux