Hi,
Am 27.11.2016 um 23:47 schrieb Grazvydas Ignotas notasas@gmail.com:
On Sun, Nov 27, 2016 at 7:08 PM, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi,
Am 27.11.2016 um 15:11 schrieb Grazvydas Ignotas notasas@gmail.com:
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.
There was no detectable coincidence of failure and thermal throttling to occur or not.
And it disappears by raising the voltage a little (at exactly the same set of low clock frequencies and temperatures).
So the only influencing factor was the voltage at high frequency OPPs and not the presence of low frequencies.
Ok I'll just trust you on that...
Of course that is just an observation without a warranty from TI.
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
and time consuming...
I've updated neon_loop to check it's calculations, if it detects an error it will now abort. I've tried to reduce number of checks to avoid stalling the processor by carefully selecting instructions in such a way that if one calculation fails, the error would propagate to the others and would be detected later. This is a different workload now and I don't know if it stresses the CPU as much as the earlier one, but maybe it'll be able to detect problems before something bad happens to the kernel, and you don't have to wonder if you've hit a kernel bug, or a CPU issue.
I have found a little time to do some tests (frequency range 250MHz ... 1250MHz) to estimate current demand (and stress):
bash-idle 100% neon-loop 310% ... 373% (as temperature rises) neon-loop2 336% ... 390% (as temperature rises)
So the new loop is stressing even more.
And now I got freezes: * before 100° was reached, i.e. processor continuously running at 1250MHz * no message printed * current consumption in freeze state ca. 205%
This all fits to the theory that the switching noise inside the OMAP becomes too big (at high frequencies, high load and high voltage).
BR, Nikolaus