On Sat, Aug 11, 2018 at 05:56:06AM -0700, Nuno Gonçalves wrote: > I will check what is the smallest delta I get to trigger the bug. > > For now, I believe in u-boot clock_sun4i.c is the one used on H3:
I think it's sun6i. > https://github.com/u-boot/u-boot/blame/master/arch/arm/mach-sunxi/clock_sun4i.c > > The frequencies listed there are different from linux DT (linus or next): > > { PLL1_CFG(31, 1, 0, 0), 1488000000}, > { PLL1_CFG(30, 1, 0, 0), 1440000000}, > { PLL1_CFG(29, 1, 0, 0), 1392000000}, > { PLL1_CFG(28, 1, 0, 0), 1344000000}, > { PLL1_CFG(27, 1, 0, 0), 1296000000}, > { PLL1_CFG(26, 1, 0, 0), 1248000000}, > { PLL1_CFG(25, 1, 0, 0), 1200000000}, > { PLL1_CFG(24, 1, 0, 0), 1152000000}, > { PLL1_CFG(23, 1, 0, 0), 1104000000}, > { PLL1_CFG(22, 1, 0, 0), 1056000000}, > { PLL1_CFG(21, 1, 0, 0), 1008000000}, > { PLL1_CFG(20, 1, 0, 0), 960000000 }, > { PLL1_CFG(19, 1, 0, 0), 912000000 }, > { PLL1_CFG(16, 1, 0, 0), 768000000 }, > > Is there any documentation where this can be cross checked? > > Also, when I used fixed-frequency, I still notice a 20% increase in > consumption when I do a stress test. Being the core voltage and frequency > the same, what can be increasing the power consumption? That sounds normal. When idle, the CPU is not consuming much, probably because of WFI instruction. regards, o. > Thanks! > > > On Friday, August 10, 2018 at 12:46:22 PM UTC+2, Ondřej Jirman wrote: > > > > On Fri, Aug 10, 2018 at 02:55:03AM -0700, Nuno Gonçalves wrote: > > > > > > > > > > > > > > > You may try a stress test and toggle the cpufreq frequency settings > > > > manually > > > > in a fast loop, to see if you can reproduce it faster. Because, > > waiting 8h > > > > or more for a crash is not optimal. :) > > > > > > > > If yes, you may try increasing delay between regulator voltage change > > and > > > > cpu > > > > frequency change. It's a regulator-ramp-delay property in dts, if that > > > > changes > > > > anything. > > > > > > > > > > I have no voltage regulator toggling. I only use frequencies that > > required > > > 1.1V, which is the lowest voltage the regulator provides. I disabled all > > > the others as they are just short term turbos, thermal can't handle them > > > for long. > > > > > > I did some stress test with mutliple cores, and it did not show any > > impact > > > on how the bug is triggered. > > > > > > Same to loop forcing frequency toggling. > > > > > > Are suggestion for some printk that I can get to guess if the crash was > > > triggered by any specific transition? > > > > It may not be related to cpufreq then if you can't reproduce it by > > manually > > changing frequencies. You may try to do it by random selection from > > available > > operating points, to be sure. But it may be some other bug in the rc > > kernel. > > > > regards, > > o. > > > > > Thanks! > > > > > > > > > -- > > > You received this message because you are subscribed to the Google > > Groups "linux-sunxi" group. > > > To unsubscribe from this group and stop receiving emails from it, send > > an email to linux-sunxi...@googlegroups.com <javascript:>. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
