On 06.03.2019 08:36, Maxime Ripard wrote:
Yes, there might at least 2 scenarios:
1.) Frequency switching itself is the problem
But that code is also the one being used by the BananaPro, which you
reported as stable.
Yes, BananaPro is stable (with exactly same configuration as far as I
know) ....
2.) lower frequency/voltage operating points are not stable.
For both scenarios: it might be possible that the crash happens on idle CPU,
high CPU load or just randomly. Therefore just "waiting" might be better
than 100% CPU utilization.But will test also 100% CPU.
Therefore it would be good to see where the voltages for different
frequencies for the SoC are defined (to compare).
In the device tree.
I'm currently testing 2 different settings on the 2 new Banana Pi R1 with
newest kernel (see below), so 2 static frequencies:
# Set to specific frequency 144000 (currently testing on Banana Pi R1 #1)
# Set to specific frequency 312000 (currently testing on Banana Pi R1 #2)
If that's fine I'll test also further frequencies (with different loads).
Look, you can come up with whatever program you want for this, but if
I insist on running that cpustress program (for the 4th time now), is
that it's actually good at it and caught all the cpufreq issues we've
seen so far.
As I wrote, I run several stress tests also with the program you
mention. But test combination require a minimum testing time to get
verifiable results.
The combinations are:
- idle cpu vs. 100% CPU
- on demand governor vs. several fixed frequencies.
So far stable testing conditions for idle CPU and 100% CPU with command
line below and cpuburn-a7 program:
# Set to max performance (stable)=> frequency 960000
# Set to specific frequency 144000 (stable)
# Set to specific frequency 312000 (stable)
TODO list to test with "idle" CPU and 100% CPU:
# Set to specific frequency 528000 (next step tested)
# Set to specific frequency 720000 (next step tested)
# Set to specific frequency 864000
# Set to specific frequency 912000
# Set to ondemand
My guess is (but it is just a guess which has to be verified):
- stable in all fixed frequencies in idle CPU and 100% CPU condition as
well as on demand and 100% CPU
- not stable with ondemand and "idle" CPU (so real frequency switching
will happen often)
Feel free to not trust me on this, but I'm not sure how the discussion
can continue if you do.
You missed my point from my previous mail: "But will test also 100%
CPU.". See command line below.
Ciao,
Gerhard
Test script:
while true; do echo "========================================"; echo -n
"CPU_FREQ0: "; cat
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq; echo -n
"CPU_FREQ1: "; cat
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq; sleep 1; done&
./stress/cpuburn-a7
_______________________________________________
arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx
