Re: Banana Pi-R1 stabil

[Maxime Ripard]

On Tue, Mar 05, 2019 at 08:21:02PM +0100, Gerhard Wiesinger wrote:
> > > > Run https://github.com/ssvb/cpuburn-arm/blob/master/cpufreq-ljt-stress-test
> > > > 
> > > > > But it doesn't explaing that it works with kernel 4.7.4 without any
> > > > > problems.
> > > > My best guess would be that cpufreq wasn't enabled at that time, or
> > > > without voltage scaling.
> > > > 
> > > Where can I see the voltage scaling parameters?
> > > 
> > > on DTS I don't see any difference between kernel 4.7.4 and 4.20.10 regarding
> > > voltage:
> > > 
> > > dtc -I dtb -O dts -o
> > > /boot/dtb-4.20.10-200.fc29.armv7hl/sun7i-a20-lamobo-r1.dts
> > > /boot/dtb-4.20.10-200.fc29.armv7hl/sun7i-a20-lamobo-r1.dtb
> > This can be also due to configuration being changed, driver support, etc.
> 
> Where will the voltages for scaling then be set in detail (drivers, etc.)?

The operating points are in the DT, but how to change it (cpufreq
drivers, clock drivers, regulators drivers) aren't, and the
configuration will tell if those drivers are included, and which
governor is going to be the default.

> > > There is another strange thing (tested with
> > > kernel-5.0.0-0.rc8.git1.1.fc31.armv7hl, kernel-4.19.8-300.fc29.armv7hl,
> > > kernel-4.20.13-200.fc29.armv7hl, kernel-4.20.10-200.fc29.armv7hl):
> > > 
> > > There is ALWAYS high CPU of around 10% in kworker:
> > > 
> > >    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
> > > 18722 root      20   0       0      0      0 I   9.5   0.0 0:47.52
> > > [kworker/1:3-events_freezable_power_]
> > > 
> > >    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
> > >    776 root      20   0       0      0      0 I   8.6   0.0 0:02.77
> > > [kworker/0:4-events]
> > The first one looks like it's part of the workqueue code.
> 
> Any guessed reason for that?

None, I'm not familiar with the workqueue code.

> > > BTW: Still stable at aboout 2,5days on both devices. So solution IS the
> > > performance governor.
> > No, the performance governor prevents any change in frequency. My
> > guess is that a lower frequency operating point is not working and is
> > crashing the CPU.
> > 
> 
> 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.

> 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.

Feel free to not trust me on this, but I'm not sure how the discussion
can continue if you do.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Attachment: signature.asc
Description: PGP signature