SIGSEGV

Thanks guys, 
Last time I used Armbian_23.5.4 with 5.15 kernel , and I had about 60 days of uptime. Today I switched for Armbian 24.05 with DTB patched . 
Im using ZFS so only what Im do, is working with older packages, and do a hold with future updates
 
I have SMB and NFS configured, I ran some tests and everything looks very good. 
Even my power consumption is down (I have 2x WD RED 4TB + Exos 18TB + WD RED 14TB + 1 SSD) and now its about 23 W
 
Currently I have 'previous' values of cpu freq: (to have some compare)
 
root@helios64:~# cat /etc/default/cpufrequtils
ENABLE=true
MIN_SPEED=408000
MAX_SPEED=1200000
GOVERNOR=ondemand
 

Actually the changes to the dtb were figured out and were proposed by @prahal and therefore it would be up to Prahal to submit a PR.
 
From my perspective there is nothing against a PR right now as the changes are sufficiently tested and have a very positive effect on stability.

There are new Armbian 24.05 images available on the Helios64 download page: both images Bookworm minimal and Jammy Desktop are based on linux 6.6.30 (download them !).
 
Again, the rtl_nic firmware (in /lib/firmware/rtl_nic) should be replaced by the version downloaded from git.kernel.org, such that the 2.5G LAN interface works correctly.
 
I would also recommend to copy the dtb attached below to /boot/dtb/rockchip/rk3399-kobol-helios64.dtb (execute 'update-initramfs -u' after that). It includes the 75mV bump of the opp states for the fast cores as suggested by @prahal, it enables the L2 cache info and it enables hs400 speed on emmc again. In particular the 75mV bump has a very positive effect on stability.
 
The bootloader that comes with it would appear to contain the Rockchip DDR blob. It should be fine. If you have an issue with u-boot, just flash linux-u-boot-edge-helios64_22.02.1_arm64 as recommended before.
 
The cpufreq ondemand governor is still the best choice. Good settings are
# cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=600000 MAX_SPEED=1800000 GOVERNOR=ondemand  
Enjoy.
 
P.S.: If you like a system more responsive to server tasks or push the 2.5G interface to the limits, some fine tuning is helpful.
 
rk3399-kobol-helios64.dtb-6.6.30-L2-hs400-opp

TLDR;
The dtb contains a 75 mV bump for all fast cores as suggested by @prahal. You can find the opp-table-1 in this thread above (posted April 19). Use device tree compiler 'dtc' to apply your own changes (link).
The dtb further contains a fix that enables hs400 speed on emmc also proposed by prahal.
There is also a change for providing L2 cache information (this is all explained in this post) - and there is also a note that 6.6.29 is stable with those modifications.
 
However, 6.6.29 and 6.6.30 bugs me with frequent transmit queue timeouts while using the 2.5G interface (NETDEV WATCHDOG: end1 (r8152): transmit queue 0 timed out 8584 ms). I could not find any combination of settings to get rid of this. Therefore I switched back to 6.6.8 - it works perfectly fine - absolutely no issues.
 
I am on linux 6.6.30 with the following configuration were armbian-hardware-optimize.service is disabled and NAS performance is restored:
(The transfer rate from Helios64 to a MacBook Pro is 280MByte/s using a 2.5G switch in between and a 2.5G USB-C Dongle (StarTech US2GC30 (rtl8156bg)) attached to the Mac)
 
root@helios64:~# cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=600000 MAX_SPEED=1800000 GOVERNOR=ondemand root@helios64:~# cat /etc/rc.local #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. for cpufreqpolicy in 0 4 ; do echo 1 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/io_is_busy echo 25 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/up_threshold echo 10 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/sampling_down_factor echo $(cat /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/cpuinfo_transition_latency) > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/sampling_rate done for i in $(awk -F":" "/xhci/ {print \$1}" < /proc/interrupts | sed 's/\ //g'); do echo 20 > /proc/irq/$i/smp_affinity done for i in $(awk -F":" "/ahci/ {print \$1}" < /proc/interrupts | sed 's/\ //g'); do echo 30 > /proc/irq/$i/smp_affinity done exit 0 root@helios64:~# systemctl disable armbian-hardware-optimize.service root@helios64:~# reboot Edit: 'sampling_rate' reduced, it was not responsive enough - now 49000 (big cores) and 40000 (little cores) in microseconds. The nominal value is the same as 'cpuinfo_transition_latency'.
 
If you are happy with 6.6.29 or 6.6.30 go ahead. For your convenience I attach the modified dtbs.
rk3399-kobol-helios64.dtb-6.6.8-L2-hs400-opp rk3399-kobol-helios64.dtb-6.6.29-L2-hs400-opp rk3399-kobol-helios64.dtb-6.6.30-L2-hs400-opp

@slymanjojo
If you don't need the transcoding - the minidlna package could be a good alternative, low resource usage and the performance mostly will depend on your network and the reproduction device.
Once HW transcoding makes it to the latest kernels, the other packages should behave much better - you're not the only one waiting for it.

Thanks @lanefu.
Another idea would be a "test week" (or whatever period makes sense) - a time when the users can download pre-release/test images of the upcoming version/release and the maintainers give timely feedback about issues found in the test kernels and user space binaries. I know that Fedora follows a similar approach (I get the notifications from the Fedora Magazine) - the main objective is to catch breaking bugs.
 
Now, if the community doesn't participate - then all complaints can be considered rants. We have to participate to make sure our systems are running as smoothly as possible. Software development, QA, Trouble shooting are task that take time/effort, as @Igor has always pointed out, we need to get involved somehow in order to contribute back. In the end Armbian is a community project - if you can't/want to donate funds, donate time and effort instead.

@Igor, is there a way to have access and test pre-release images from the official Armbian build system (nightly images should be fine)?
That way we can participate on the QA process and help raise flags when pre-released changes break the stable builds.
I understand that you do not have an Helios64 to test, and so as part of the community we should be able to help in that regard.

There are a number of modifications that have been suggested that people implement to address certain issues.
 
The ones I can find are:
- In /boot/armbianEnv.txt:
extraargs=libata.force=3.0 - If doing debugging, also add:
verbosity=7 console=serial extraargs=earlyprintk ignore_loglevel  
- In /boot/boot.cmd
regulator dev vdd_log regulator value 930000 regulator dev vdd_center regulator value 950000 and then run:
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr  
- In /etc/default/cpufrequtils:
ENABLE=true MIN_SPEED=408000 MAX_SPEED=1800000 GOVERNOR=ondemand (or 1200000 instead of 1800000)
 
- And if using ZFS:
for disk in /sys/block/sd[a-e]/queue/scheduler; do echo none > $disk; done  
 
I've gathered these from a variety of threads. Am I missing any here?

Hello @Igor, @Werner,
I'm open to collaborating to the armbian project, my background is on software development and system administration and I have a small Helios64 to test things with.

Enjoy your time off - looking forward to new products from you guys.

Enjoy your time off - looking forward to new products from you guys.

My comment might be late to the party - if there was a possibility to add an optional display and a few user-configurable buttons to the Front Panel, that would be great.
I know it would mess a bit with the airflow, but it could be used for system monitoring and few other specific use cases.

My comment might be late to the party - if there was a possibility to add an optional display and a few user-configurable buttons to the Front Panel, that would be great.
I know it would mess a bit with the airflow, but it could be used for system monitoring and few other specific use cases.

My comment might be late to the party - if there was a possibility to add an optional display and a few user-configurable buttons to the Front Panel, that would be great.
I know it would mess a bit with the airflow, but it could be used for system monitoring and few other specific use cases.

Hi all, you could download the SATA firmware update at https://cdn-kobol-io.s3-ap-southeast-1.amazonaws.com/Helios64/SATA_FW/Helios64_SATA_FW_update_00021_200624.img.xz
 
Instruction:
1. Download the sd card image
2. Flash the image into a microSD card
3. Insert microSD card into Helios64 and power on. Helios64 should automatically boot from microSD. If Helios64 still boot from eMMC, disable the eMMC 
4. Wait for a while, the system will do a reboot and then power off if firmware flashing succeed.
   If failed, both System Status and System Fault LEDs will blink
5. Remove the microSD card and boot Helios64 normally. See if there is any improvement.
 
Our officially supported stock firmware can be downloaded from https://cdn-kobol-io.s3-ap-southeast-1.amazonaws.com/Helios64/SATA_FW/Helios64_SATA_FW_factory_00020_190702.img.xz. If there is no improvement on newer firmware, please revert back to this stock firmware.
 
SHA256SUM:
e5dfbe84f4709a3e2138ffb620f0ee62ecbcc79a8f83692c1c1d7a4361f0d30f *Helios64_SATA_FW_factory_00020_190702.img.xz 0d78fec569dd699fd667acf59ba7b07c420a2865e1bcb8b85b26b61d404998c5 *Helios64_SATA_FW_update_00021_200624.img.xz  

Sigh. Except that doesn't solve the problem. Now it's just cron filling up the log.
 
New solution, using the sleep option. Modified helio64-ups.service:
[Unit] Description=Helios64 UPS Action [Install] WantedBy=multi-user.target [Service] #Type=oneshot #ExecStart=/usr/bin/helios64-ups.sh Type=simple ExecStart=/usr/local/sbin/powermon.sh  
Modified powermon.sh:
#!/bin/bash #7.0V 916 Recommended threshold to force shutdown system TH=916 # Values can be info, warning, emerg warnlevel="emerg" while [ : ] do main_power=$(cat '/sys/class/power_supply/gpio-charger/online') # Only use for testing: # main_power=0 if [ "$main_power" == 0 ]; then val=$(cat '/sys/bus/iio/devices/iio:device0/in_voltage2_raw') sca=$(cat '/sys/bus/iio/devices/iio:device0/in_voltage_scale') # The division is required to make the test later work. adc=$(echo "$val * $sca /1" | bc) echo "Main power lost. Current charge: $adc" | systemd-cat -p $warnlevel echo "Shutdown at $TH" | systemd-cat -p $warnlevel # Uncomment for testing # echo "Current values:" # echo -e "\tMain Power = $main_power" # echo -e "\tRaw Voltage = $val" # echo -e "\tVoltage Scale = $sca" # echo -e "\tVoltage = $adc" if [ "$adc" -le $TH ]; then echo "Critical power level reached. Powering off." | systemd-cat -p $warnlevel /usr/sbin/poweroff fi fi sleep 20 done  

Might help to add to the ZFS page to do something like this when done:
for disk in /sys/block/sd[a-e]/queue/scheduler; do echo none > $disk; done  
(Assuming all 5 disks are using ZFS.)

We are coming up soon with a change that will finally improve DVFS stability.

@allen--smithee Thanks for the feedback.

The problem of this post is solved !!
Your fans with an efficient thermal pad and SSD drives are 18w and 10db peak.
I very rarely exceed 12w in a day and the unit is completely inaudible.
Except for doing these tests which do not reflect the reality of normal use at all.

@ gprovost
As we might expect, there is a little spread of the pads on the outer edges of the processor, but also on the edge of the radiator
and so you were right, there is no need to leave the inductors bareheaded.
Now I think 19x19 is enough for the dimensions of the cpu thermical pad with a 1.5mm. 
I redid the separation between the CPU Pad and the rest of the board and put pieces of pad in the slots of the inductors. 
You don't know if it will be possible so, nevertheless now we know what we need for our next blends at home ;).
 
P6 and P7> PWM = 35
P6 & P7> PWM = 50 is my new PWMMAX on Fancontrol
P6 et P7> PWM = 255
 
 
@SIGSEGV
If you are interested in this solution.
I recommend TP-VP04-C 1.5mm for your helios64 (2 plates of 90x50x1.5mm)
 
 

I shared the design of the thermal pad, showing that the whole area below heatsink is cover with thermal pad by default.
 

 
@allen--smithee That's very valuable feedback, I think we will need to review our approach on thermal pad.
One factor we had to take in consideration is also ease of installation on the factory line.

After one hour of disassembly, cleaning, cutting, installation and reassembly.
My helios64 has gelid thermal pad GP-Ultimate solutions whose manufacturer boasts a small 15W.mK.
 
I think I just solved my ventilation problem for this generation and the following ones.
I will do the tests within a week but for the moment Helios64 remains very cold even under full load.

Yes, either a smaller SSDs focused version - or a solution to fit more SSD or 2.5 drives with a SATA port multiplier on the same space as the 5 drives, to increase storage density.
If later revisions of the main CPU board or newer boards can be retro fit into these cases, it would make for a smooth and straight upgrade path.

@slymanjojo
If you don't need the transcoding - the minidlna package could be a good alternative, low resource usage and the performance mostly will depend on your network and the reproduction device.
Once HW transcoding makes it to the latest kernels, the other packages should behave much better - you're not the only one waiting for it.