gprovost

We need some times to look, it won't be straight forward... some patched would need to be rework most probably, some patched would also need to be remove since some of our stuff made it upstream but not all. With @aprayoga we will start to look and report in this thread or new one. Igor is not talking about the -20c tweak which was anyway just a cosmetic thingy for all mvebu platform. There is a lot of kernel patches for mvebu and we need to insure all apply well on 4.19... for Helios4 one or two might be a bit tricky. Anyway we will work on it.

Thanks for the info and pointer. Now I understand where this -20°C tweak we asked about here comes from It means it wasn't so smart to remove already the tweak... well at least it will already be aligned when armbian mvebu next jump to 4.19 or 5.x The kernel change you mention are from this commit and effectively it didn't made it to v4.14 https://github.com/torvalds/linux/commit/8c0b888f6610d0ebbc4bdfb52d2fef9f4a11adfc I'm also not 100% sure how this bitwise tweak works :/ FYI The Marvell errata (#132698) mentioned in the commit is an internal errata, it wasn't even made public.

@uzair Ahhh we found the issue OMV install watchdog service by default. When the system is put in standby / suspend mode the watchdog is not stopped, therefore since nothing will be kicking the watchdog in that state, the watchdog will reset the system after 60sec. You will need to disable watchdog service. $> sudo systemctl disable watchdog Note: you will need to reboot after you disable the watchdog in order to ensure the watchdog is stopped. It's quite odd that systemctl doesn't try to stop the watchdog before doing the suspend... and then restart the watchdog when waking-up. But well at the same time some would say it's odd to have a watchdog on a system that is meant to be put in suspend mode. Also it seems there is a hardware limitation on Armada SoC watchdog (orion_wdt) that doesn't allow the watchdog to be stop during runtime for security reason... so will need to investigate more.

@djurny Ok thanks, keep us updated. @uzair Even though it's most probably unrelated to the standby issue on which Aditya will help you. What's the hardware time and the system time before you put your system in standby ? Do the following command : System time $> date Hardware Clock time (RTC) $> hwclock -r @seawolfssn Ok understood, well it looks like your PSU is faulty unable to provide 12V while still providing enough voltage for the different buck converters (5V and 3.3V rails) to operate. Please PM me and will arrange to send you a new PSU.

@djurny We not sure what it could be. BTW is it a system from batch1 or batch2 ? We are asking because if it's batch2 and as you said the fan still spin after system has hanged, then it means PWM it is running, so the system is not completely hang. In order to narrow down the issue, could you swap the PSUs between your 2 Helios4 systems, to see if it could be a faulty PSU ? In any case, if we can't figure out the root cause, then we will proceed to a replacement of the board. @seawolfssn Sounds like power budget issue, the overall peripherals current consumption exceed the max power budget of Helios4. I'm a bit lost at some point in your explanation, what combination you tried with which HDD and in which order. Maybe a table would help that also show the exact HDD brand + model you are testing. Please note there are 2 power rails for the SATA HDDs, the 5V and the 12V. While the 12V rail is directly coming from the AC/DC PSU, the 5V rail is generated by a buck converter (step-down converter). This buck converter has several protection (over current, over voltage, temperature, etc..) that will switch off the buck converter if something wrong and latch it in this state until a full power cycle. So if by plugging in and out devices you triggered the buck converter protection, plugging/swapping devices might not work because the buck is latching in off state... you need to do a full power cycle (unplug / plug PSU). The same things apply for USB devices, there is a dedicated 5V rails for the USB ports with the same kind of protection and behavior described above.

Sure, no rush... on my side I don't have any package to push. BTW what will be the sftp address ?

Great ! Just sent you my pub key by PM ;-)

@djurny Yeah normally kernel message should be output to serial. Well let us know if you catch anything with your monitoring setup. BTW which HDD models are using ? Do you have USB devices connected ? I'm wondering if it could a power rail issue.

@MarcC Yes Helios4 supports Wake on Timer. It's true that it's a feature we forgot to advertise in our wiki, will need to had a page on the Real Time Clock and Wake on Time features. You can use rtcwake command to put your system in suspend mode until a specified wakeup time. Example : sudo rtcwake -m mem -s 30 Put system in suspend-to-ram mode and will wake up after 30 sec sudo rtcwake -m mem --date '2019-03-25 08:27' Put system in suspend-to-ram mode and will wake up on March 25 2019 at 08:27 For more information man rtcwake and man hwclock are your friends. On your early question regarding "Wake on GPIO" : To implement WoL we used "Wake on GPIO" feature. The Ethernet PHY interrupt pin is connected to SoC GPIO (MPP18) that is configured as a wakeup-source. When you enable WoL on the PHY, the PHY will trigger the MPP18 on reception of magic packets, which in turn will wake up the system. Any GPIO can be configured as wakeup-source. As you figured, the GPIO header J12 on the board is not direct SoC GPIO, but provided through an I2C IO expander. However this IO expander, like the Ethernet PHY, has also an interrupt pin connected to a SoC GPIO (MPP23), any event on header J12 will trigger MPP23. MPP23 could be also configured as wakeup-souce. Actually IO expander pins could be also configured as wakeup source, it would set the upstream interrupt as wakeup capable automatically.

What you say concern people mounting on a 64bit Kernel a File System created on 32 bit Kernel. This is not the issue we are talking about. Our limitation is that simply you cannot address a File System > 16TB with a 32bit Kernel because of page cache limitation. I'm not aware of possible work around even with other File System than EXT. The only solution is to use a FUSE union file system to merge two or more partitions into one big volume. MergerFS : https://github.com/trapexit/mergerfs (It's available as a Debian package.) @9a3eedi @fpabernard You guys don't want to give a try to MergerFS ?

@tuxd3v Don't turn ON 64bit feature on partitions mounted on a 32bit system, this is completely wrong.

@9a3eedi Thanks for your feedback. Sooner or later we will do a refresh of Helios4 with a 64bit SoC... but it's not going to happen so soon. Have you tried MergerFS ? It could be used to union your different volumes into a single one. I'm not sure though if there might be some limitation because of the 32bit arch.

Just for info I updated the libssl1.0.2 cryptodev patch to work with latest libssl1.0.2 debian deb (libssl1.0.2_1.0.2r) https://wiki.kobol.io/cesa/#network-application-encryption-acceleration So if some people wanna test offload crypto operation while using apache2 or ssh for example ;-) You can also find a pre-build dpkg here if you want to skip the compile steps.

I just told you what the patch does, so you should be able to figure if the target file was modified or not. If you are unsure then better wait the next OMV LUKS plugin upgrade, hopefully this new feature might be added by then.

@jimandroidpc Well does the patch get applied ? the patch just modifies 2 lines in /usr/share/php/openmediavault/system/storage/luks/container.inc to add -c aes-cbc-essiv:sha256 to the crypsetup luksFormat command. Anyhow I just rise a change request on the OMV LUKS plugin and it seems the maintainer is going to make the improvement since this change could benefit many ARM SoC based board : https://forum.openmediavault.org/index.php/Thread/11592-LUKS-disk-encryption-plugin/?postID=198390#post198390 @fpabernard Well hopefully one day there will be a refresh revision of Helios4.

Helios4 changes : Add support for Wake-on-LAN Enable WoL by default on eth0 Adjust fancontrol config to make fan spin even in idle Thanks @Igor

@Igor Could we imagine another mechanism than to use git as an "upload front-end" ? Using git as some kind of spool folder is really not ideal. For instance if I clone today the armbian upload git project the size of the objects is already reaching 1.2 GB for a project that is essentially just a structure of empty folders. I even see the following error during cloning Cloning into 'upload'... remote: Enumerating objects: 75, done. remote: Counting objects: 100% (75/75), done. remote: Compressing objects: 100% (61/61), done. kex protocol error: type 7 seq 49316022.52 MiB | 6.67 MiB/s remote: Total 844 (delta 33), reused 40 (delta 14), pack-reused 769 Receiving objects: 100% (844/844), 1.22 GiB | 6.03 MiB/s, done. Resolving deltas: 100% (251/251), done. The easier would be to provide a FTP service with the same structure and limited access to people you grant right to upload.

@jimandroidpc I attached a dirty patch to hard code the right cipher in OMV LUKS plug-in. So when you create an encrypted device under OMV it will use the right cipher : aes-cbc-essiv:sha256 It's far to be the ideal way, we should actually request to the developer of the OMV LUKS plug-in to add the possibility for user to choose the cipher. To apply the patch sudo patch -d/ -p0 < helios4-omv-luks.patch helios4-omv-luks.patch

Hahah cool to hear that. The idea of Helios4 was to fulfill one specific scope : NAS. There are a lot of awesome boards out there but often they are trying to do too many things. For instance if we do a refresh of Helios4 with a new SoC that has some display output, I'm pretty sure we would decide to not expose it... in order to stick to a pure headless NAS server concept. Well we hope we will carry on this path of "disruptive" DIY NAS solution with future project, but it's not tomorrow that we will steal the market share of entry level proprietary NAS

@lanefu Humm yeah a bit tangential and honestly not really sure of the message you trying to share.

I don't think the OMV interface allows you to specify which cipher. You need to create the encrypted device via command line. Will need to check if we can tweak OMV in some way to make it use by default the cipher that can be accelerated by the CESA engines.

@jimandroidpc Please refer to this thread where quite a bunch of benchmarking numbers and important remarks were shared : https://forum.armbian.com/topic/8486-helios4-cryptographic-engines-and-security-accelerator-cesa-benchmarking/ Did you used the right cipher : aes-cbc-essiv:sha256 ? Other cipher won't be accelerated by the CESA engine. Anyway I encourage to follow up on the thread I shared.

@movanet You can first define deadtime = 10 in /etc/samba/smb.conf which is recommended to close inactive connections and avoid exhausting server's resources.

@movanet Based on your 2 log files, your system is completely overloaded by way too many rclone and smbd instances which trigger Out-of-Memory killer (oom-killer) which in turn will start to kill processes to try to free memory... this will make the system unstable and unresponsive. It seems it's even generating some mmc (sdcard) error, maybe because of the continuous swapping. So you need to do some proper setting / tunning for rclone to insure it doesn't kill your system.

@movanet Please run armbianmonitor -u command and share the link it will generate here. Ideally you run it when the issue appear.