On Sun, Nov 27, 2016 at 11:02 AM, H. Nikolaus Schaller hns@goldelico.com wrote:
So it is just a very peculiar symptom of a low-voltage/high-frequency partial freeze.
Well it could be even simpler than that - it could be some corruption caused by incorrect results from some CPU processing that has left some semaphores locked or similar. We have seen that a lot on pandora where games would start to show glitches or misbehave when people overclock, but still carry on and not hang. Such problems have been reported as software bugs to me several times, which was extremely annoying.
That's why I don't like your use of low frequencies that are not approved by TI. If it doesn't hang it doesn't mean it works. The low frequencies are usually entered when CPU is idle and doing nothing, so the problems are unlikely to trigger, but then when you do a test that constantly thermal throttles (like the one you recently posted), the CPUs run at 100% at a low unapproved OPP and is quote likely they'll fail there instead of the high frequency, and you then misinterpret the result thinking it failed at the high frequency.
Sure, saving power and reducing temperatures is great, by we should do that optimization after we know the SoC works in conditions specified by TI. As we don't have low OPP data from TI (like we had for OMAP3), we'll need careful tests that do lots of calculations without stalling the CPUs and verifies the calculation results and run them for a long time on lots of boards forced to those low OPPs to prove they indeed work. This is all challenging to do. Sticking random low OPPs like it's done now is irresponsible and is very likely to give wrong test results, making the test useless.
GraÅžvydas