On 12/17/2014 08:01 PM, Viresh Kumar wrote:
On 17 December 2014 at 22:46, Kevin Hilman khil...@kernel.org wrote:
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
On Thu, Dec 18, 2014 at 2:37 PM, Nishanth Menon n...@ti.com wrote:
script download fail does imply my farm has still issues to resolve..
but anyways.. more or less we are back operational again since it was
broken by next-20141216
I'm not seeing any more failures in next-20141218 either.
On 09:37-20141217, Viresh Kumar wrote:
On 17 December 2014 at 02:33, Nishanth Menon n...@ti.com 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
On 17 December 2014 at 20:58, Nishanth Menon n...@ti.com wrote:
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
On Wed, Dec 17, 2014 at 10:27 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 17 December 2014 at 20:58, Nishanth Menon n...@ti.com wrote:
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
[+ Tero]
On Tue, Dec 16, 2014 at 8:07 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 17 December 2014 at 02:33, Nishanth Menon n...@ti.com wrote:
http://storage.armcloud.us/kernel-ci/next/next-20141216/arm-multi_v7_defconfig/lab-khilman/boot-omap5-uevm.html
[2.071996] [ cut
On Wed, Dec 17, 2014 at 9:16 AM, Kevin Hilman khil...@kernel.org wrote:
[...]
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
On 17 December 2014 at 22:13, Nishanth Menon n...@ti.com wrote:
I do realize that i did have different opinion given bootloader screw
ups. Given that we have discovered a potentially bad configuration (in
this case for some reason almost ALL TI platforms have bad
configuration - could be due
On 17 December 2014 at 22:46, Kevin Hilman khil...@kernel.org wrote:
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
FYI... New boot failures in today's linux-next for omap4-panda-es and
omap5-uevm:
http://status.armcloud.us/boot/?lab-khilmanfailomap
The omap3-beagle-xm one has been fixed by Tero, but the fix hasn't hit
-next yet. I haven't had a chance to bisect these yet.
Kevin
-- Forwarded
+Viresh and linux-pm
On 12/16/2014 10:59 AM, Kevin Hilman wrote:
FYI... New boot failures in today's linux-next for omap4-panda-es and
omap5-uevm:
http://status.armcloud.us/boot/?lab-khilmanfailomap
On 17 December 2014 at 02:33, Nishanth Menon n...@ti.com 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!
[
12 matches
Mail list logo
