it doesn't apply until i manually change ENABLE to true in /etc/default/cpufrequtils

board is opi pc and opi zero and im using latest CLI image

Providing logs with 

armbianmonitor -u

 helps with troubleshooting and significantly raises chances that issue gets addressed.

On 10/3/2023 at 1:31 AM, 0ka said:

it doesn't apply until i manually change ENABLE to true in /etc/default/cpufrequtils

I can confirm that in current images that I examined, in /etc/default/cpufrequtils, ENABLE is set to false.
In older images that I examined ENABLE was set to true.

This affects all boards.   Without ENABLE being set, the armbian-config CPU speed governor settings simply don't work.

Normally when cpufrequtils is installed, and a CPU driver exists, then the installer sets ENABLE to true.  But cpufrequtils is pre-installed by Armbian build.

Before logging a Jira issue I thought that I should investigate further to try and understand what had changed led me to
this change tagged as [HIGHLY CONTENTIOUS CHANGE].
@rpardini  do you have any insight into this change or advice?

Please check whether this issue might exist for other boards too:

 

3 hours ago, schwar3kat said:

this change tagged as [HIGHLY CONTENTIOUS CHANGE].
@rpardini  do you have any insight into this change or advice?

 

Yeah that. Well, cpufrequtils and big.little clusters don't mix well as you probably noticed.

cpufrequtils itself has been deprecated for well over a decade.

Since cpufrequtils was being inflicted on otherwise perfectly working, DT-controlled boards, we've disabled it by default.

Boards that are proven to require it can re-enable it directly on the board as you've already found out or in the Armbian board file via 'CPUFREQUTILS_ENABLE=true'

All that said, the real, kernel-supported alternative, cpupower, requires kernel-tools build which is currently not provided by Armbian (nor is usbipd, perf, nor any other kernel userspace tool, due to the complexities of release-dependent building of parts of kernel which is normally userspace-agnostic).

 

Good point about

18 hours ago, rpardini said:

big.little clusters

I wouldn't have noticed, because personally, I haven't seen a need to use this armbian-config functionality but people are apparently using it so what do I know?

The main issue, as I understand it, is that an armbian-config function doesn't work as it could reasonably be expected to work.
I will mull over and test an idea and perhaps I can come up with a simple way to control expectations based on the ENABLED state.

Edit: AR-1883