gprovost

@achurak The RED led issue is unrelated to the HDD harness. The issue is that the LED on front panel might be touching the metal sheet opening on the side creating a short and lighting up the LED. To fix that, just loosen the 2 screws of the front panel a bit, push back the front panel and tighten back. Another solution is to put a small piece of tape on the side of the LED to be sure not contact with the metal sheet can happen. It's something we will fix in next revision.

@SymbiosisSystems How the stability so far with LK5.9 ?

I know you dismissed PSU problem from the beginning, but how long you have been running the system with same PSU for ?

@JPW Maybe you contact us at support@kobol.io to see if we should send you a new HDD harness. Hahhaa good one.

You performance is not aligned with what we see on our side. Instead of getting 2.35 Gbit/s when TX offload works (e.g on LK4.4), with TX checksum offload disable, you should get around 1.8 Gbit/s You sure TX offload is off on both side ?

Yes watchdog service is not installed by default. apt-get install watchdog

@Zageron Yeah please formulate a clear question. To check if tx offloading is on or off ethtool -k eth1 | grep tx-checksum Currently TX checksum offload for all network interfaces on rockchip64 family is disable in Armbian by default.

@amreo What HDD brand and model are you using ?

Where did you get this new PSU ?

Have you tried with Kernel 4.4 ? For me it still looks like issue related to TX checksum offload not working properly on LK5.x I cannot reproduce the issue on my setups. Can you post some iperf output of the USB Startech 1Gbps issue. When doing the iperf test with the USB Startech 1Gbps please insure the 2.5GbE is disconnected, just to be sure traffic is transiting only through the Startech adapter.

Hmmm could be a manufacturing mistake on the harness cable. You can contact us to support@kobol.io in order to request a harness replacement.

Keep us updated of the result once you manage to downgrade the Barracuda SSD 120 to SATA 3.1 specs. Here the link you are referring to, that might be useful for others : https://www.seagate.com/sg/en/support/kb/why-does-my-computer-with-a-barracuda-ssd-sometimes-say-no-bootable-device-detected-during-startup/ Unfortunately cannot find such tool for Linux. Yes we ware of such issue, we will fix that in next iteration of the enclosure.

@FredK Yes the 2 PSU you listed are ok. Any 4-Pin PSU replacement for Synology with 12V and at least 8A output will work since we use the same pinout. Hmmm you right but still it doesn't completely dismiss the possibility of PSU issue. What model of 2.5' HDD you are using ? If the watchdog is disabled the system won't be able to reboot/reset on its own when it hangs. So does your system still reboot on its own with watchdog disable ?

@Mangix The issue is that since your system still able to startup then it means without load the PSU is able to provide 12V, but under load it starts to drop most probably way below 11V. So it's not trivial to test to be honest. One way would be to run the system with less HDD hookup to see if system don't reset anymore, but I guess if you have a RAID array then not possible to do that easily.

How long both you ( @Mangix and @FredK ) have been running your Helios64 setup ? We had a lot of case of Helios4 faulty PSU (AC/DC power adapter) after one year of usage. The capacitors used in the PSU are not fulfilling their hour rating :-/ We have completely changed PSU supplier for our new product Helios64. You can find a good replacement unit on Amazon : https://www.amazon.com/TAIFU-4-Pin-12V-8-33A-Replacement/dp/B07NCG1P8X

Yes please disable it and restart your system. Because if the system reboot (reset) on its own without watchdog service running, then a possible reason is that the PSU is starting to fail and during operation the output voltage drop resulting into a hard reset.

Can you first reply my question...

@Mangix @FredK Can you please if yes or no, the watchdog service is running ( systemctl status watchdog.service ) ? If it's not enable but your system reboot on its own then it's a bit strange. This could help to narrow down the issue.

Ok we will have to look at it. @Heisath @aprayoga

I didn't read properly your first message, and miss out a very important information : your disk formatted in NTFS :-/ You know that there can be a big write performance penalty using NTFS partition on Linux since it is handle in userspace via libfuse. Can you do a local write test with dd to the NTFS partition to see the performance ? Honestly you should migrate to another file system than NTFS. I did some test again and I max out gigabit when writing from PC --> Helios64 over SMB or FTP.

When it hangs, it automatically reboots ? Do you have the watchdog service running ( systemctl status watchdog.service ) ?

Can you update the /boot/armbianEnv.txt with the following in order to increase log output : verbosity=7 extraargs=no_console_suspend ignore_loglevel Then you will need to keep the serial open and hope to catch something when it happens. Does it crash easily ?

It could be a faulty HDD harness cable. Could you try to swap cables connected to SATA port 1 to SATA port 2 on the board. Then check if HDD slot 1 still doesn't work and HDD slot 2 still works. This way we can confirm it's a wire issue.

For now WoL feature is not yet supported on Helios64. It's our on TODO list. Once ready we will announce it and add a page on our wiki to explain how to use.. We cannot provide ETA because it's link to an issue (failure to resume from suspend mode) that we haven't resolved yet.

In current revision (rev1.2) the 2.5GbE Magjack center point is connected to GND while it should instead be connected to 2.5V rail. All the board delivered so far don't have the fix since we discovered the issue once all board were already manufactured and in warehouse. Also we realized that sometimes the 2.5GbE port without the fix can still perform OK in 1000Mb speed mode when connected to some network switch. Not sure why, could be that the default combination of MDI settings between the switch and the Heliso64 are perfectly aligned by chance. I don't have a network crossed cable around, but wondering what would be the outcome. Maybe you can try ? Side note : We have just finished to fix 50+ spare boards that will be soon for sale. It will be easy to identify them since there will be a small patching wire like in our blog post : https://blog.kobol.io/2020/11/13/helios64-2-5g-ethernet-issue/