gprovost

Yes you can upgrade. The issue of instability wasn't related to the kernel actually but to some silly bug in Armbian hardware optimization script.

Please contact us to support@kobol.io if you want to order a new PSU.

@JeffDwork Well noted on your feedback, yes we will improve cable routing in next revision. As for the screws and spacer on the picture those are to be used when installing a device in the M.2 SATA slot. https://wiki.kobol.io/helios64/m2/#installation

@AurelianRQ You post is a bit messed up (can you edit/fix it ?). You can find multi-gigabit switch at 150euros check Zyxel XGS1010-12 or even QNAP QSW-1105-5T. As for the instruction to fix the 1000Mb mode on the 2.5Gbe port, it was posted above.

Well according to your ethtool ouput. Your switch only advertise 10 and 100baseT/Full. What switch model it is ? Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full I think you need to try again with the other switch you mentioned about. What switch model it is ?

Yes we are aware of that, something wrong with fusb302 driver, @aprayoga is looking into it.

@TDCroPower Here the small hardware tweak ;-) WARNING Please understand we are not responsible for any damage you might do to the board !

@jessie You mean even the system led doesn't blink after 20-30 sec you powered up the system ? Yes the maskrom mode would be the next step : https://wiki.kobol.io/helios64/maskrom/

@wurmfood and @357up it could be an issue with the wire harness. Can you do more try by swapping the cable between the bay slots and sata ports in order to narrow down the problem to the wire harness. If it's the case then you can contact us to support@kobol.io and we will help you from there. @AurelianRQ Regarding the issue for 2.5GbE port that doesn't perform properly when used in 1000Mb mode, unfortunately there is no fix that can be done by software. But it's actually pretty easy to fix on the board itself, it only requires to solder one wire between 2 points. Our mistake is that we didn't connect center tap of the 2.5Gb MAGJACK to 2.5V power rail (connected to ground instead) in order to provide common mode for MDI signals which is required for 1000Mb mode somehow. We will post a PCN bulletin to explain better this limitation and how to fix it for people who are up for a bit of soldering. @aegiap Unfortunately your link aggregation is going to be impacted to the issue mentioned above. The 2.5GbE doesn't perform properly in 1000Mb mode.

Hi All, we finally figured out the issue with the latest build (20.08.13) and actually it wasn't related to the Kernel. There was a silly mistake in Armbian hardware optimization script that ended up skipping applying all the required performance and stability tweak for Helios64. This has been fixed. Now we need to wait new image and dpkg are generated and propagated on the repos. Actually the instructions we gave on our latest blog post, were a bit pointless since it wasn't bound to kernel version We will post something on our blog as soon as new Armbian version is ready. @djurny Thank for the Snapraid feedback and suggested tweak on SATA speed to avoid I/O errors. We will to look that closely to confirm it's not rather an issue with your harness cable. SATA 1 port is the one with the longest cable could be look closely here. @fromport Yeah I think at the end it wasn't really a DVFS issue but just missing hw optimization tweak as stated above. For now stick to performance governor and once new armbian dpkg for Helios64 are ready and you upgraded then you can try to revert to on-demand governor (default settings) and let us now how it works. @eClapton Noted on the instructions / clarification required. We are improving our Wiki every week. Hot swap procedure is a good point ;-) Didn't have this one on our TODO list. We also welcome any contribution to your wiki : https://github.com/kobol-io/wiki @Dmitry Antipov Thanks for the pointer we will look at it. Doesn't seem anyone try to port rockchip RNG engine to mainline. I guess we could add it via patch to Armbiam @piter75 In a kind of similar topic people asked us how crypto engine works on RK3399, it's something we will address soon. @Jaques-Ludwig Yeah as pointed by @Werner you can refer to official install doc You can also look for some pointer to an old guide we did for our previous product, it's the same steps, just that the components version are older : https://wiki.kobol.io/helios4/nextcloud/ But anyhow would be great that the install via armbian-config works properky. Let's put that on the TODO list. @dancgn You should create a dedicated Armbian thread on Mayan install via armband-config since it's not really related to hardware. Would be easier to troubleshot other it's going to get lost here. You can also rise an issue on here with detailed logs. Armbian-config tool is in big need of contributors, so don't expect it will be fix so soon, maybe you can try to figure it out yourself and fix it in armbian-config ;-)

@fromport Yeah it seems we haven't found the sweet voltage spot that works for everyone.

@fromport First time we see this kind of crash message, but looking online it seems it isn't an unknown event on other rk3399 board. Could do the same test that trigger this crash but first set the governor to performance. cpufreq-set -c 0 -g performance cpufreq-set -c 4 -g performance cpufreq-info to check the governor has been change Trying to figure out if it's still a DVFS config issue.

For now WoL is not supported yet. Still in progress because suspend mode doesn't work properly.

This blog post / issue report only applies to Helios64, not Helios4. Maybe corruption as you point out, or BTRFS bug on latest kernel... hard to say. You can revert to previous kernel using armbian-config > System > Other

My point is just to collect as much info as possible on use cases that generate crash in order to prioritize focus.

So you have tuned php-fpm, mariadb ? I haven't done extensive test of NC on Helios64, but I know that on Helios4 (with only 2GB RAM) i had to tune properly NC otherwise system will hangs (and reset because of watchdog). Not only because of OOM but also just too many thread / child process spawned overloading the system. I never tested NC in container though so maybe that doesn't apply to your use case. ( Just for reference : https://docs.nextcloud.com/server/19/admin_manual/installation/server_tuning.html )

Have you tuned your nextcloud install for a 4GB RAM system ? No we are not saying that for now. We split 2 weeks ago the install page into 4 sub pages in order to add the eMMC install instruction. BTW we just added a new section called Recovery, where we explained how to use Maskrom mode.

What page is broken ??

You right. No excuse on our side, we are behind schedule and not up to expectation on the software maturity, maybe we should have stick LK4.4 (from rockchip) and forget about Linux mainline for now :-/ However we are still working at improving the stability and we are optimistic that very soon, it will get better. Right now as you know LK5.8.16 is for some reason (we still can't figure out) unstable vs 5.8.14 We also realized that OMV install was removing some tx offloading tweak. So a lot of little things here and there that we only discover along the way. BTW regarding this crash are you sure tx offload on eth1 was disable ?

@barnumbirr Not really sure what happened to your setup and it's going to be hard to help will all those sequence of event you posted. I would suggest you just do a fresh install. You can find previous build here : https://archive.armbian.com/helios64/archive/

Euhhh wait, can you share the link of the PSU you buy because it's not always guaranty it's the same pin out (unless it's PSU for synology). Here a good replacement : https://www.amazon.com/TAIFU-4-Pin-12V-8-33A-Replacement/dp/B07NCG1P8X

Before going any further, yes you need a multi-meter to narrow down the issue which is probably just a faulty PSU and need to be replaced.

@flower On which kernel are you running ? Did you revert to LK 5.8.14 ? You can use watchdog service for that.

What do you get when you use -R option on iperf3 client side in order do a download test from your PC to Helios64. Here my iperf3 just done now. PC (iperf3 -s) <-- 5G --> Netgear MS510TX <-- 2.5G --> Helios64 (iperf3 -c) root@helios64:~# iperf3 -c 10.10.20.254 Connecting to host 10.10.20.254, port 5201 [ 5] local 10.10.20.3 port 56716 connected to 10.10.20.254 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 155 MBytes 1.30 Gbits/sec 0 2.13 MBytes [ 5] 1.00-2.00 sec 168 MBytes 1.41 Gbits/sec 0 2.26 MBytes [ 5] 2.00-3.00 sec 166 MBytes 1.39 Gbits/sec 0 5.03 MBytes [ 5] 3.00-4.00 sec 166 MBytes 1.39 Gbits/sec 0 5.03 MBytes [ 5] 4.00-5.00 sec 168 MBytes 1.41 Gbits/sec 0 6.23 MBytes [ 5] 5.00-6.00 sec 168 MBytes 1.41 Gbits/sec 0 6.23 MBytes [ 5] 6.00-7.00 sec 168 MBytes 1.41 Gbits/sec 0 6.23 MBytes [ 5] 7.00-8.00 sec 168 MBytes 1.40 Gbits/sec 0 6.23 MBytes [ 5] 8.00-9.00 sec 166 MBytes 1.39 Gbits/sec 0 6.23 MBytes [ 5] 9.00-10.00 sec 169 MBytes 1.42 Gbits/sec 0 6.23 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.62 GBytes 1.39 Gbits/sec 0 sender [ 5] 0.00-10.00 sec 1.62 GBytes 1.39 Gbits/sec receiver iperf Done. root@helios64:~# iperf3 -c 10.10.20.254 -R Connecting to host 10.10.20.254, port 5201 Reverse mode, remote host 10.10.20.254 is sending [ 5] local 10.10.20.3 port 56720 connected to 10.10.20.254 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 268 MBytes 2.24 Gbits/sec [ 5] 1.00-2.00 sec 280 MBytes 2.35 Gbits/sec [ 5] 2.00-3.00 sec 272 MBytes 2.28 Gbits/sec [ 5] 3.00-4.00 sec 280 MBytes 2.35 Gbits/sec [ 5] 4.00-5.00 sec 280 MBytes 2.35 Gbits/sec [ 5] 5.00-6.00 sec 280 MBytes 2.35 Gbits/sec [ 5] 6.00-7.00 sec 280 MBytes 2.35 Gbits/sec [ 5] 7.00-8.00 sec 278 MBytes 2.33 Gbits/sec [ 5] 8.00-9.00 sec 278 MBytes 2.33 Gbits/sec [ 5] 9.00-10.00 sec 280 MBytes 2.34 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 2.71 GBytes 2.33 Gbits/sec 702 sender [ 5] 0.00-10.00 sec 2.71 GBytes 2.33 Gbits/sec receiver As you can see the sending perf are not good because of the TX offloading feature disable. But the RX perf are as expected.

Yes as I mentioned previously there is design issue with the 2.5GbE interface when used in 1000Mb/s mode (What you see in your last iperf), however no impact in 2500baseT mode. So now why you get only 547 Mbits/s when connected to your 10G switch it's strange... maybe your 10G port doesn't support 2500baseT mode. As requested in my last message can show the output of ethtool eth1 on Helios64 when connected to your 10G port switch. Edit: ok so it's in 2500Mb/s speed mode. How's you machine running iperf server is connected to the switch ? 1G or 10G or ?