lkml.org 
[lkml]   [2019]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Banana Pi-R1 stabil
From
Date
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




\
 
 \ /
  Last update: 2019-03-06 21:03    [W:0.069 / U:6.116 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site