gprovost

@axeleroy Hi, could try to the following tweak and then report to us if it helps stabilizing your system. Run armbian-config, go to -> System -> CPU And set: Minimum CPU speed = 1200000 Maximum CPU speed = 1200000 CPU governor = performance

@SymbiosisSystems Have you tried each tweak individually ?

Around 3W/m-K. Dimension and thickness below , the small 21x21x1mm square is the one above the RK3399 SoC : Let's clarify, you can use Helios64 board in passive cooling mode on its own, but if the board is installed in the provided enclosure along HDDs device then you definitely need active cooling.

DVFS patch were removed quite some time ago in Armbian since it wasn't stable and the gain in term of power consumption & thermal was negligible.

Hi, there already some threads opened for the same topic, so not very efficient if things are spread all over the place. You can try one of the following 2 tweaks : 1/ Change CPU governor to Performance, and optionally reduce the CPU speed to keep the system run cool. armbian-config > System > CPU Minimum CPU speed = 1200000 Maximum CPU speed = 1200000 CPU governor = performance So far this tweak is the one that showed the best result on instability linked to DVFS. 2/ New tweak for which we are collecting feedback, for now to be tested without the above tweak, Add following lines to the beginning of /boot/boot.cmd regulator dev vdd_log regulator value 930000 regulator dev vdd_center regulator value 950000 run mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr and reboot. Verify whether it can improve stability. Thanks for giving us feedback on how each of the above tweaks impact stability of your setup.

@tionebrr With CPU governor set as performance and frequency set 1.8GHz you have a fully stable system or you still encountered crash ?

@qtmax Yes i observe the same thing with your test script between LK 5.8 and 5.9. That's super great that you managed to pin point the upstream change that is the root cause. I haven't had the time to test the patch though. You could just rise a PR to add the revert patch here : https://github.com/armbian/build/tree/master/patch/kernel/mvebu-current What do you think @Heisath ? root@helios4:~# uname -r 5.9.14-mvebu root@helios4:~# bash test_script Direct: read: 361 MB/s write: 120 MB/s RAID0: read: 399 MB/s write: 92.4 MB/s RAID10 far: read: 407 MB/s write: 49.0 MB/s RAID10 near: read: 398 MB/s write: 50.3 MB/s RAID6: read: 396 MB/s write: 51.6 MB/s ----------------------------------------- root@helios4:~# uname -r 5.8.18-mvebu root@helios4:~# bash test_script Direct: read: 328 MB/s write: 146 MB/s RAID0: read: 335 MB/s write: 237 MB/s RAID10 far: read: 337 MB/s write: 130 MB/s RAID10 near: read: 335 MB/s write: 153 MB/s RAID6: read: 335 MB/s write: 87.8 MB/s

@Vin I think you issue might not be related to the thread. Most likely some bad physical connection, please check by opening the back panel that the HDD is well inserted in the SATA backplane connector.

@qtmax Ok let us reproduce that on our side and confirm your observations.

@qtmax You can refer to our wiki page on CESA engine to accelerate crypto : https://wiki.kobol.io/helios4/cesa/ There is also an old thread on that topic : Unfortunately it might not be of big help because as stated on our wiki here by default you cannot use CESA engine for OpenSSH for Debian Buster while it is possible under Debian Stretch. However it seems possible if you recompile OpenSSH to disable sandboxing. https://forum.doozan.com/read.php?2,89514 The above forum link, which is more up to date than our wiki, give some instruction on how to use cryptodev on Buster, but yeah it's a bit experimental... worth a try. Regarding RAID, I would go for RAID10 if you are looking a the best balance between redundancy and cpu load + resync time.

RK3399 has a single PCIe 2.1 x 4 lanes port, you can't split the lanes for multi interfaces unless you use a PCIe switch which is an additional component that would increase a lot the board cost. That's clearly the intention, we don't want either to restart form scratch the software and documentation :P Yes this will be fixed, it was a silly design mistake. We will also make the back panel bracket holder with rounder edges to avoid user to scratch their hands :/ We will post soon how to manage fan speed based on HDD temperature (using hddtemp tool), that would make more sense than current approach. You can already find an old example : https://unix.stackexchange.com/questions/499409/adjust-fan-speed-via-fancontrol-according-to-hard-disk-temperature-hddtemp

Maybe you guys could participate to the following thread

@jsfrederick You only need the fix if you intend to use the 2.5GbE Interface (LAN2) at 1Gbps speed. So in your case you don't need the fix.

@Salamandar Thanks for setting up this poll, that's cool of you. @Alexander Eiblinger Well noted, and you can be sure we are already working on those improvements.

@Werner Hahaha yes we are working at improving the design ;-) More news soon.

@fr33s7yl0r Updated your title to make it more friendly. If we could have made it 6x SATA port at that time, with one port dedicated to the M.2 slot, you can be sure we would have done it. We could have taken a different approach using a PCIe Switch, but it would have increase significantly the board. Any board design is about finding the best recipe within a budget for a list of use cases with the less tradeoffs possible. The M.2 SATA port on our Helios64 was an addition to support more use cases to the product, even though yes it wasn't perfect that the port has to be shared.

You can also check all the certification and conformity document for the PSU we provide with Helios64 : https://wiki.kobol.io/helios64/docs/#psu We have designed Helios64 with safety and protection in mind... no shortcut.

Have you tried to start this psd manually to see what is the failure ?

@clostro @yay @fbernard You using also a 2.5GbE interface on your client side ? can you describe your network setup (e.g which network switch model you are using, and what is the network interface model on your computer).

Since you have access to serial console. Can you check that your network is configured properly on Helios64. Take note that OMV5 install wipe out any fixed IP configuration made through armbian-config tool.

Hmmm it could be a hardware issue with the PWM GPIO controlling the fan. Quite unfortunate that it happens on both. Please contact us at support@kobol.io to see how we can help. Might need you to send us back the board for repair or replacement.

This is more a question to ask on openmediavault forum.

@devman Based on your measure (the 12V fluctuating when HDD are connected), it's a dying PSU. So you just need to replace it. In which countries are you located ? We can provide you link for a replacement PSU that you can order on Amazon.

Can you check with a DC voltmeter the voltage on the 4-pin connector ? You should read 12V Update: Nevermind, I just saw your issue was already addressed in another thread.

In case you haven't looked up this section of our wiki : https://wiki.kobol.io/helios64/usb/#helios64-as-direct-attached-storage-das-device