Helios64 unstable with 23.8.1 Bullseye and 6.1.50-current-rockchip64

[TDCroPower]

@bunducafe that's strange, because exactly with your setting the system crashes for me.
I was able to finally install OMV yesterday with Min + Max set to 1416000 + ondemand and the system stayed active the whole time.
I have now set to Min=408000 and Max=1200000 ondemand and see if the system continues to survive that.
If so, I can finally transfer it to the SSD and take it live permanently.

 

I started with the image Armbian_21.08.2_Helios64_bullseye_current_5.10.63.img.xz and with "apt update && apt upgrade" updated it to 23.8.1 + 6.1.50.

Then downgraded via armbian-config to Kernel 5.15.93 with image 23.02.2, set the cpu freq and freeze the kernel.

I also added this...

cpufreq.off=1

... to the /boot/armbianEnv.txt which was recommended from @prahal on the end of the "freeze" thread.

However, I could not find out exactly what these settings are supposed to be good for.
Maybe someone has an idea?

 

edit:

I have just found something interesting here which fits perfectly to our hardware.
Here a min/max is not simply set over all CPUs, but separately on the different types of installed CPUs.
With the following command you can see the CPU limits and it fits to the suggested configs...

Spoiler

root@helios64:~# cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 40.0 us.
  hardware limits: 408 MHz - 1.42 GHz
  available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 408 MHz and 1.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 408 MHz (asserted by call to hardware).
  cpufreq stats: 408 MHz:39.99%, 600 MHz:0.64%, 816 MHz:0.00%, 1.01 GHz:0.00%, 1.20 GHz:2.38%, 1.42 GHz:57.00%  (193)
analyzing CPU 1:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 40.0 us.
  hardware limits: 408 MHz - 1.42 GHz
  available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 408 MHz and 1.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 408 MHz (asserted by call to hardware).
  cpufreq stats: 408 MHz:39.99%, 600 MHz:0.64%, 816 MHz:0.00%, 1.01 GHz:0.00%, 1.20 GHz:2.38%, 1.42 GHz:57.00%  (193)
analyzing CPU 2:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 40.0 us.
  hardware limits: 408 MHz - 1.42 GHz
  available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 408 MHz and 1.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 408 MHz (asserted by call to hardware).
  cpufreq stats: 408 MHz:39.99%, 600 MHz:0.64%, 816 MHz:0.00%, 1.01 GHz:0.00%, 1.20 GHz:2.38%, 1.42 GHz:57.00%  (193)
analyzing CPU 3:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 40.0 us.
  hardware limits: 408 MHz - 1.42 GHz
  available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 408 MHz and 1.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 408 MHz (asserted by call to hardware).
  cpufreq stats: 408 MHz:39.99%, 600 MHz:0.64%, 816 MHz:0.00%, 1.01 GHz:0.00%, 1.20 GHz:2.38%, 1.42 GHz:57.00%  (193)
analyzing CPU 4:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 4 5
  CPUs which need to have their frequency coordinated by software: 4 5
  maximum transition latency: 51.0 us.
  hardware limits: 408 MHz - 1.80 GHz
  available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz, 1.61 GHz, 1.80 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 408 MHz and 1.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 408 MHz (asserted by call to hardware).
  cpufreq stats: 408 MHz:38.27%, 600 MHz:0.79%, 816 MHz:0.07%, 1.01 GHz:0.00%, 1.20 GHz:3.87%, 1.42 GHz:56.84%, 1.61 GHz:0.00%, 1.80 GHz:0.16%  (166)
analyzing CPU 5:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 4 5
  CPUs which need to have their frequency coordinated by software: 4 5
  maximum transition latency: 51.0 us.
  hardware limits: 408 MHz - 1.80 GHz
  available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz, 1.61 GHz, 1.80 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 408 MHz and 1.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 408 MHz (asserted by call to hardware).
  cpufreq stats: 408 MHz:38.27%, 600 MHz:0.79%, 816 MHz:0.07%, 1.01 GHz:0.00%, 1.20 GHz:3.87%, 1.42 GHz:56.84%, 1.61 GHz:0.00%, 1.80 GHz:0.16%  (166)

 

Edited October 13, 2023 by TDCroPower

[bunducafe]

vor 7 Stunden schrieb TDCroPower:

I started with the image Armbian_21.08.2_Helios64_bullseye_current_5.10.63.img.xz and with "apt update && apt upgrade" updated it to 23.8.1 + 6.1.50.

Then downgraded via armbian-config to Kernel 5.15.93 with image 23.02.2, set the cpu freq and freeze the kernel.

 

Could you try get the 5.10.63 image on sd-card and then go to kernel 5.15.93 via armbian-config and then apply apt update / apt upgrade? I somehow think that with updating to the latest kernel and then switch back to an older kernel the system already got corrupted.

[TDCroPower]

@bunducafe i will give it a try.

Anyway, I now have an active system copied to the SSD, so I can run a fresh test again with the microSD.
Found the downgrade variant itself is not good, because thereby in the root directory broken symlinks are.

[TDCroPower]

@bunducafe I just tried it, first flashed the 21.08.2, then increased the kernel to 5.15.93, then set the freeze.
Now when I do an "apt update" the 6.1.50 is displayed and also installed as soon as I run "apt upgrade".

 

How exactly did you do it so that it does not update the kernel during an "apt upgrade"?
What I also wonder, when I updated to 23.8.1 + 6.1.50 and then downgrade to 5.15.93 with image 23.02.2, afterwards when the kernel freeze this was also shown to me in the welcome message and an apt upgrade did not update it.

[bunducafe]

Am 15.10.2023 um 21:55 schrieb TDCroPower:

I just tried it, first flashed the 21.08.2, then increased the kernel to 5.15.93, then set the freeze.
Now when I do an "apt update" the 6.1.50 is displayed and also installed as soon as I run "apt upgrade".

 

That's kind of strange. I freeze the kernel via armbian-config as mentioned in previous posts and it holds it on my machine. Of course you can use the CLI as well. Then it should work with the apt-mark command.

 

Are you running OMV on top of Armbian? Or are you using a different nas software?

[TDCroPower]

@bunducafe no in this case OMV is not installed, only armbian.
Do you do an update with "apt update && apt upgrade" or do you start it via armbian-config >>> System >>> Firmware "Update all packages and firmware" ?

[bunducafe]

@TDCroPower as stated above. I use the old image and manually update the kernel until 5.15.93 and then freeze the kernel. Some reboots might be required anyway. Once it is up and running again I would then perform apt update && apt upgrade. Because of the frozen kernel the firmware should not update to any higher version same es the packages a higher kernel would require.

 

[bunducafe]

I usually do an update only via OMV. But no matter which way you use once the kernel is frozen it should only update the packages accordingly until that version. At least that's what it is in my case.

 

In the past I just put in the terminal commands you mentioned. I believe the update process via armbian-config is identical (someone correct me pls if I am wrong) - and so is the OMV command, too.