Hi,
Am 27.11.2016 um 15:11 schrieb Grazvydas Ignotas notasas@gmail.com:
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.
Ok, this is very plausible.
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.
Ouch.
That's why I don't like your use of low frequencies that are not approved by TI.
I use them for my board but nothing else... The final OS installed can be different from my setup and has to be discussed.
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.
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...
to do. Sticking random low OPPs
The values I use are not randomly chosen but based on CMOS design assumptions.
like it's done now is irresponsible and is very likely to give wrong test results, making the test useless.
I don't see any wrong test results in this case. I have seen such rcu stalls only happen if the voltage is close to its lower limit and that lower voltage limit is what I wanted to empirically find out for this board. For that kind of test it doesn't matter how the OMAP5 freezes or stumbles. I was just puzzled that it could be partially freezing. So my cautious conclusion is that is not working in this situation as well and my table was marked orange or red.
And in all my tests done so far it does not make any difference to include or exclude the lower frequencies. We had freezes before we even tried lower frequencies and still have them with.
Rather, all the test results show me that we have a problem at high voltages and trying to run higher CPU clock requires to raise voltage to a point where the overvoltage freezes occur. Never with rcu stall or other messages. They simply stop every sign of activity.
My question was to understand if the rcu stall message at low voltages gives us some more hints. Obviously it does not and that is all answers I am looking for.
BTW: I just finished booting the EVM with 1GHz + 1.5GHz @ 1.25V and it works without noticeable problems at overvoltage. So it can run at OPPs completely outside the green range for the Pyra CPU.
And I was able to estimate (by using the B2B connectors as a shunt resistor) total current consumption between:
bash-idle 100% bash-loop 200% neon-loop 270%
So this means the OMAP draws 2.7 times as much Amperes when running neon-loop than in bash-idle (if run with a single frequency OPP list: 1GHz).
I noticed that there is also a small temperature effect (+20% at 100° compared to 50°) but it is small compared to the code or overall OPP influence.
So I totally agree that low frequency/voltage OPPs must be verified to work if we want to reduce power demand.
Since estimates indicate that we could be able to reduce power demand by factor 3 to 7 this is something I think we *must* try to achieve for a portable device intended for daily use.
But not now.
BR and thanks, Nikolaus