lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 6 Mar 2019 21:03:00 +0100
From:   Gerhard Wiesinger <>
To:     Maxime Ripard <>
Cc:, Chen-Yu Tsai <>,
        LKML <>,
        Florian Fainelli <>,
Subject: Re: Banana Pi-R1 stabil

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.



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& 

Powered by blists - more mailing lists