Trillien

Hi @prahal, Yes, for few weeks I took the habit to use the serial console to better understand whether the boot crashes or is stuck at some steps (I've got a long long network config step with systemd-networkd). The message appears after u-boot gives the hand to linux, and is part of the very first lines where linux checks the hard drive filesystem.

Hi @TDCroPower Have you got any issue with systemd-networkd service ? I systematically have a timeout as it seems waiting for all network interface to be ready. $ systemctl status systemd-networkd-wait-online.service × systemd-networkd-wait-online.service - Wait for Network to be Configured Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; enabled; preset: disabled) Drop-In: /etc/systemd/system/systemd-networkd-wait-online.service.d └─override.conf Active: failed (Result: exit-code) since Fri 2024-04-19 16:33:57 CEST; 18min ago Docs: man:systemd-networkd-wait-online.service(8) Process: 1188 ExecStart=/lib/systemd/systemd-networkd-wait-online (code=exited, status=1/FAILURE) Main PID: 1188 (code=exited, status=1/FAILURE) CPU: 48ms I use end0 network interface. The other enx646266d00b79 isn't connected I've got a bridge br0 with a virtual tap0 interface (OpenVPN) podman runs a container and enable the interface veth7198de08 and the bridge cni-podman. $ networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 end0 ether enslaved configuring 4 enx646266d00b79 ether no-carrier configured 5 br0 bridge routable configured 6 tap0 ether enslaved configuring 7 cni-podman0 bridge routable unmanaged 8 veth7198de08 ether enslaved unmanaged 7 links listed.

By the way, Running Armbian 23.08.0-trunk Bookworm with Linux 6.6.8-edge-rockchip64 I notice an error at the beginning of linux boot. "mdadm: initramfs boot message: /scripts/local-bottom/mdadm: rm: not found" Seems an old one as I follow these instructions for Helios4 to solve the issue https://wiki.kobol.io/helios4/mdadm/#fix-mdadm

Hi @prahal I've just done a test with your cpufreq-switching-2 program. I'm running Helios64 on Armbian 23.08.0-trunk Bookworm with Linux 6.6.8-edge-rockchip64 I've started with LITTLE (CPUL = 1) The program ran the 100 loops without issue. Then I ran with big (CPUB = 1) So far it failed at the 6th loop Before a third run, I tried to change the interrupt allocation on xhci and ahci as you suggested Please note the interrupts may vary after reboot (e.g. ahci was 76-80, after reboot it is 75-79) # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 18: 0 0 0 0 0 0 GICv3 25 Level vgic 20: 0 0 0 0 0 0 GICv3 27 Level kvm guest vtimer 23: 7947 8876 6014 7156 18916 24271 GICv3 30 Level arch_timer 25: 6601 5232 4476 4609 11249 4343 GICv3 113 Level rk_timer 31: 0 0 0 0 0 0 GICv3 37 Level ff6d0000.dma-controller 32: 0 0 0 0 0 0 GICv3 38 Level ff6d0000.dma-controller 33: 0 0 0 0 0 0 GICv3 39 Level ff6e0000.dma-controller 34: 0 0 0 0 0 0 GICv3 40 Level ff6e0000.dma-controller 36: 915 0 0 0 0 0 GICv3 132 Level ttyS2 37: 0 0 0 0 0 0 GICv3 147 Level ff650800.iommu 38: 0 0 0 0 0 0 GICv3 149 Level ff660480.iommu 39: 0 0 0 0 0 0 GICv3 151 Level ff8f3f00.iommu, ff8f0000.vop 40: 0 0 0 0 0 0 GICv3 150 Level ff903f00.iommu, ff900000.vop 41: 0 0 0 0 0 0 GICv3 75 Level ff914000.iommu 42: 0 0 0 0 0 0 GICv3 76 Level ff924000.iommu 43: 0 0 0 0 0 0 GICv3 85 Level ff1d0000.spi 44: 0 0 0 0 0 0 GICv3 84 Level ff1e0000.spi 45: 0 0 0 0 0 0 GICv3 164 Level ff200000.spi 46: 1399 0 0 0 1775 0 GICv3 142 Level xhci-hcd:usb1 47: 30 0 0 0 0 0 GICv3 67 Level ff120000.i2c 48: 0 0 0 0 0 0 GICv3 68 Level ff160000.i2c 49: 5031 0 0 0 0 0 GICv3 89 Level ff3c0000.i2c 50: 540 0 0 0 0 0 GICv3 88 Level ff3d0000.i2c 51: 0 0 0 0 0 0 GICv3 90 Level ff3e0000.i2c 52: 0 0 0 0 0 0 GICv3 129 Level rockchip_thermal 53: 0 0 0 0 0 0 GICv3 152 Edge ff848000.watchdog 54: 0 0 0 0 0 0 GICv3-23 0 Level arm-pmu 55: 0 0 0 0 0 0 GICv3-23 1 Level arm-pmu 56: 0 0 0 0 0 0 rockchip_gpio_irq 9 Edge 2-0020 57: 0 0 0 0 0 0 rockchip_gpio_irq 10 Level rk808 63: 0 0 0 0 0 0 rk808 5 Edge RTC alarm 67: 2 0 0 0 0 0 GICv3 94 Level ff100000.saradc 68: 0 0 0 0 0 0 GICv3 97 Level dw-mci 69: 0 0 0 0 0 0 rockchip_gpio_irq 7 Edge fe320000.mmc cd 70: 0 0 0 0 0 0 GICv3 81 Level pcie-sys 72: 0 0 0 0 0 0 GICv3 83 Level pcie-client 74: 0 0 0 0 0 0 ITS-MSI 0 Edge PCIe PME, aerdrv 75: 0 489 0 0 524 0 ITS-MSI 524288 Edge ahci0 76: 0 0 237 0 0 904 ITS-MSI 524289 Edge ahci1 77: 0 0 0 489 31578 0 ITS-MSI 524290 Edge ahci2 78: 0 0 0 0 249 0 ITS-MSI 524291 Edge ahci3 79: 0 0 0 0 0 248 ITS-MSI 524292 Edge ahci4 83: 14093 0 0 0 0 0 GICv3 43 Level mmc1 84: 0 0 0 0 0 0 rockchip_gpio_irq 5 Edge Power 85: 0 0 0 0 0 0 rockchip_gpio_irq 3 Edge User Button 1 86: 0 0 0 931 0 0 GICv3 44 Level end0 87: 5 0 0 0 0 0 rockchip_gpio_irq 2 Level fsc_interrupt_int_n 88: 0 0 0 0 0 0 GICv3 59 Level rockchip_usb2phy 89: 0 0 0 0 0 0 GICv3 135 Level rockchip_usb2phy_bvalid 90: 0 0 0 0 0 0 GICv3 136 Level rockchip_usb2phy_id 91: 0 0 0 0 0 0 GICv3 60 Level ohci_hcd:usb4 92: 0 0 0 0 0 0 GICv3 58 Level ehci_hcd:usb3 93: 0 0 0 0 0 0 GICv3 137 Level dwc3-otg, xhci-hcd:usb5 94: 0 0 0 0 0 0 GICv3 32 Level rk-crypto 95: 0 0 0 0 0 0 GICv3 146 Level ff650000.video-codec 96: 0 0 0 0 0 0 GICv3 87 Level ff680000.rga 97: 0 0 0 0 0 0 GICv3 145 Level ff650000.video-codec 98: 0 0 0 0 0 0 GICv3 148 Level ff660000.video-codec 99: 0 0 0 0 0 0 rockchip_gpio_irq 2 Edge gpio-charger 100: 0 0 0 0 0 0 rockchip_gpio_irq 27 Edge gpio-charger 101: 2 0 0 0 0 0 GICv3 51 Level panfrost-gpu 102: 0 0 0 0 0 0 GICv3 53 Level panfrost-mmu 103: 0 0 0 0 0 0 GICv3 52 Level panfrost-job IPI0: 1384 1517 1472 1311 4816 7551 Rescheduling interrupts IPI1: 12225 10971 9100 9240 10161 26978 Function call interrupts IPI2: 0 0 0 0 0 0 CPU stop interrupts IPI3: 0 0 0 0 0 0 CPU stop (for crash dump) interrupts IPI4: 2213 2003 2357 2402 2137 1671 Timer broadcast interrupts IPI5: 598 601 747 496 1106 784 IRQ work interrupts IPI6: 0 0 0 0 0 0 CPU wake-up interrupts Err: 0 I reallocated the interrupts over the little core. # echo 0 > /proc/irq/46/smp_affinity_list # echo 1 > /proc/irq/75/smp_affinity_list # echo 2 > /proc/irq/76/smp_affinity_list # echo 3 > /proc/irq/77/smp_affinity_list # echo 0 > /proc/irq/78/smp_affinity_list # echo 1 > /proc/irq/79/smp_affinity_list Then I ran the program on the big again (CPUB = 1) And I reach the 25th loop before it failed.

I was curious about how cpufrequtils can manage different policies over several cpus. Actually it can only dictate one set over the 6 cpus. For info, I've just found a post about having a change on cpufrequtils that can manage different frequency sets over the cpus (4x cpus at 400-1400MHz and 2x cpus at 400-1800MHz). #To get individual cpus current frequencies $ cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq #To get individual cpus governor (note there is no one governor for one cpu) $ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor #To collect existing frequency policies $ ls -al /sys/devices/system/cpu/cpufreq/ I'm now testing the script... Edit: Not probant ! It reboots with "400-1400MHz schedutil" and "400-1800MHz conservative" governors.

Here is a short feedback on my Helios64 experience. Few years ago I had troubles at having a stable system running OMV5 on Buster. I decided to move to Bullseye and OM6 and finally achieved a stable environment. Absolutely no reboot, but for OMV6 Photoprism extension I couldn't run. I recently tried to move to a fresh Bookworm install with OMV7. I felt it was painful to track within the forum each and every necessary changes to the image. It took me 2 tries before I apprehended the effect of the changes, and I carefully followed the instructions to apply the changes in the right order. Since my last install 5 days ago, it seems I now have something stable again.

For info, probably related to this issue : https://github.com/openwrt/openwrt/issues/14377

Nop, I didn't get a chance to reach these steps at the first install. It reboot during update-initramfs, part of apt install openmediavault substep. However, /etc/default/cpufrequtils were already changed to "schedutil"

I plan to use OMV Photoprism extension that's managed as a container by OMV. As I remember, OMV doesn't manage containers with Docker but Podman. Not tested yet. Did you have a look at?

Hi @prahal, I'm running Armbian_23.5.4_Helios64_bookworm_current_6.1.36 on my Helios64. In /etc/armbian-release, BOARDFAMILY was rk3399 As per your post, I manually changed BOARDFAMILY to rockchip64. $ cat /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=helios64 BOARD_NAME="Helios64" BOARDFAMILY=rockchip64 BUILD_REPOSITORY_URL=https://github.com/armbian/build BUILD_REPOSITORY_COMMIT=173ed85 VERSION=23.08.0-trunk LINUXFAMILY=rockchip64 ARCH=arm64 IMAGE_TYPE=stable BOARD_TYPE=csc INITRD_ARCH=arm64 KERNEL_IMAGE_TYPE=Image FORCE_BOOTSCRIPT_UPDATE= VENDOR=Armbian REVISION=23.08.0-trunk BOOTSCRIPT_FORCE_UPDATE="no" BOOTSCRIPT_DST="boot.cmd" BRANCH=current That's dirty, but that let me have access to the newest armbian package releases. Can you please advise whether you know a cleaner way to match to the new BOARDFAMILY for Helios64 and its rockchip processor?

Sorry, I meant dpkg --configure -a I've got a theory on /etc/default/cpufrequtils change. Searching within openmediavault github repository for "Deploying Service Configurations ...", there is only one result : deb/openmediavault/debian/openmediavault.postinst According to openmediavault.postinst, the script echoes this message and runs omv-salt deploy run cpufrequtils 237 ######################################################################## 238 # Deploy various services when the package is installed the first time. 239 ######################################################################## 240 if [ -z "$2" ]; then 241 # Disable default nginx site. 242 nginx_dissite default || : 243 244 # Deploy the configuration for various services. 245 echo "Deploying service configurations ..." 246 LANG=C.UTF-8 omv-salt deploy run --no-color --quiet \ 247 apt cpufrequtils chrony rsyslog \ 248 watchdog monit rrdcached avahi ssh nginx collectd \ 249 phpfpm issue sysctl systemd systemd-logind || : 250 fi Thanks to https://docs.openmediavault.org/en/stable/various/advset.html#environmental-variables, I learn the configuration files used by omv-salt is stored at /srv/salt/omv Looking at the deploy stage in /srv/salt/omv I find a cpufrequtils folder kobol@helios64:~$ ls -al /srv/salt/omv/deploy/cpufrequtils/ total 20 drwxr-xr-x 3 root root 4096 Apr 5 15:58 . drwxr-xr-x 39 root root 4096 Apr 5 17:04 .. -rw-r--r-- 1 root root 2387 Mar 9 12:58 default.sls drwxr-xr-x 2 root root 4096 Apr 5 15:58 files -rw-r--r-- 1 root root 916 Mar 9 12:58 init.sls default.sls tells us the source file used by salt to configure /etc/default/cpufrequtils is files/cpufrequtils.j2 $ nano /srv/salt/omv/deploy/cpufrequtils/default.sls ... configure_default_cpufrequtils: file.managed: - name: "/etc/default/cpufrequtils" - source: - salt://{{ tpldir }}/files/cpufrequtils.j2 - template: jinja - context: cpufreq: {{ config.cpufreq }} - user: root - group: root - mode: 644 ... Finally, files/cpufrequtils.j2 calls for OMV_CPUFREQUTILS_MAXSPEED, OMV_CPUFREQUTILS_MINSPEED and OMV_CPUFREQUTILS_GOVERNOR $ nano /srv/salt/omv/deploy/cpufrequtils/files/cpufrequtils.j2 {%- set max_speed = salt['pillar.get']('default:OMV_CPUFREQUTILS_MAXSPEED', '0') -%} {%- set min_speed = salt['pillar.get']('default:OMV_CPUFREQUTILS_MINSPEED', '0') -%} {%- set governor = salt['pillar.get']('default:OMV_CPUFREQUTILS_GOVERNOR', salt['grains.filter_by']({ "default": "ondemand", "amd64": "conservative", "i386": "conservative", "armhf": "schedutil", "arm64": "schedutil", "armel": "schedutil" }, grain="osarch")) -%} {%- if cpufreq -%} ENABLE="true" {%- else -%} ENABLE="false" {%- endif %} GOVERNOR="{{ governor }}" MAX_SPEED="{{ max_speed }}" MIN_SPEED="{{ min_speed }}" The point is these values are first defined in the install script at line 543... after omv-salt is called on cpufrequtils at line 337 543 # set defaults in /etc/default/openmediavault 544 omv_set_default "OMV_CPUFREQUTILS_GOVERNOR" "${GOVERNOR}" 545 omv_set_default "OMV_CPUFREQUTILS_MINSPEED" "${MIN_SPEED}" 546 omv_set_default "OMV_CPUFREQUTILS_MAXSPEED" "${MAX_SPEED}" As per /srv/salt/omv/deploy/cpufrequtils/files/cpufrequtils.j2, there isn't any values defined yet in /etc/default/openmediavault. Thus : governor takes "schedutil" max_speed is 0 min_speed is 0

Openmediavault 7 (sandworm) is now released. Using my Helios64 with Linux 6.6.8, I followed the instructions on https://github.com/OpenMediaVault-Plugin-Developers/installScript to install OMV7. First attempt failed during the update of linux image by initramfs. The device rebooted by itself. This was due to CPUfrequency parameters that were changed in between, probably by one of OMV necessary package. Previously were : $ cat /etc/default/cpufrequtils ENABLE="true" GOVERNOR="ondemand" MAX_SPEED="1800000" MIN_SPEED="408000" And were updated to : $ cat /etc/default/cpufrequtils ENABLE="true" GOVERNOR="schedutil" MAX_SPEED="0" MIN_SPEED="0" I changed back the governor to "ondemand" using armbian-config > System > CPU. $ sudo armbian-config Needed to clean the install with : $ sudo dpkg-reconfigure -a And lauch again the install script : $ sudo curl -sSL https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | sudo bash To be sure OMV is aligned with my CPUfrequency parameters, I checked : $ cat /etc/default/openmediavault ... OMV_CPUFREQUTILS_GOVERNOR="ondemand" OMV_CPUFREQUTILS_MINSPEED="408000" OMV_CPUFREQUTILS_MAXSPEED="1800000" Those parameters were collected by the install script from /etc/default/cpufrequtils : https://github.com/OpenMediaVault-Plugin-Developers/installScript/blob/master/install Be aware OMV remove ssh-users group from /etc/ssh/sshd_config. It still possible to ssh using root. $cat /etc/ssh/sshd_config ... AllowGroups root _ssh ... As sshd_config is now controlled by OMV and may be replaced unexpectedly, you should include your user in _ssh group $ sudo usermod -a -G _ssh youruser

So, I've just tried the procedure once more : I flashed the bookworm image onto a sd card. I booted my Helios64 using the sd card (It started like a charm !), and I downloaded every pieces of the cake. I set the CPU limit using "on-demand" I disable the armbian.list for apt update I added the files at /lib/firmware/rtl_nic/ I replaced the dtb file at /boot/dtb/rockchip for hs400 support and L2 cache I set the nic offload options At this point I copied the sd card to emmc using armbian-config. However, as it asks to Power Off, I refused and quitted. Actually, during its last step of the copy, armbian-config automatically writes its version of u-boot onto emmc. Thus, even if we've changed the bootloader on mmcblk1 (emmc), it's then overwritten during the copy to emmc. After copying the OS onto emmc, but still using sd card, I changed the bootloader on mmcblk1 (emmc) I shutdown the system, removed the sd card, and boot on emmc (still without any issue) I switched to linux 6.6.8 and reboot. Once more, the system starts without trouble. I finally ran sbc-bench Hi @TDCroPower, I really thank you for your post which helped me to finally achieve a clean install of linux 6.6.8 on emmc after hours of frustration. To guide people without confusion on the result, you may probably reorder steps and have the Bootloader update (6.) after Copying from sd card to emmc (10).

I've just been defeated by my Helios64 trying to have Linux 6.6.8 on emmc. Actually, as I move the OS from the SD card and then restart the device from emmc, I encounter unexpected reboots and freezes. So, I'm resigned and will try to have things more stable using the SD card. Keep you informed.

Thank you ebin-dev. Works fine now ! For info, after moving the OS to emmc, the system failed starting for 3 times. It encountered Internal error: Oops - undefined instruction during Linux 6.6.8 startup. I still have an issue with rk3288-crypto. But it doesn't seem to impact the system a lot : Apr 01 14:18:12 helios64 kernel: rk3288-crypto ff8b0000.crypto: will run requests pump with realtime priority Apr 01 14:18:12 helios64 kernel: rk3288-crypto ff8b0000.crypto: Register ecb(aes) as ecb-aes-rk Apr 01 14:18:12 helios64 kernel: rk3288-crypto ff8b0000.crypto: Register cbc(aes) as cbc-aes-rk Apr 01 14:18:12 helios64 kernel: rk3288-crypto ff8b0000.crypto: Register ecb(des) as ecb-des-rk Apr 01 14:18:12 helios64 kernel: rk3288-crypto ff8b0000.crypto: Register cbc(des) as cbc-des-rk Apr 01 14:18:12 helios64 kernel: rk3288-crypto ff8b0000.crypto: Register ecb(des3_ede) as ecb-des3-ede-rk Apr 01 14:18:12 helios64 kernel: rk3288-crypto ff8b0000.crypto: Register cbc(des3_ede) as cbc-des3-ede-rk Apr 01 14:18:12 helios64 kernel: rk3288-crypto ff8b0000.crypto: Register sha1 as rk-sha1 Apr 01 14:18:12 helios64 kernel: rk3288-crypto ff8b0000.crypto: Register sha256 as rk-sha256 Apr 01 14:18:12 helios64 kernel: rk3288-crypto ff8b0000.crypto: Register md5 as rk-md5 Apr 01 14:18:12 helios64 kernel: rk3288-crypto ff8b8000.crypto: can't request region for resource [mem 0xff8b8000-0xff> Apr 01 14:18:12 helios64 kernel: rk3288-crypto ff8b8000.crypto: Crypto Accelerator not successfully registered Apr 01 14:18:12 helios64 kernel: rk3288-crypto: probe of ff8b8000.crypto failed with error -16

Hi @TDCroPower About rtl_nic firmware, as instructed I've downloaded the 9 files and copied them into /lib/firmware/rtl_nic I've got an error at startup : Apr 01 00:10:55 helios64 kernel: r8152 2-1.4:1.0: checksum fail Apr 01 00:10:55 helios64 kernel: r8152 2-1.4:1.0: unable to load firmware patch rtl_nic/rtl8156a-2.fw (-14) Do you encounter this error too?

Hi @ebin-dev, The link to https://imola.armbian.com/apt/pool/main/l/linux-u-boot-helios64-edge/linux-u-boot-edge-helios64_22.02.1_arm64.deb is dead. There's another version on Imola : linux-u-boot-helios64-edge_24.2.1_arm64__2022.07-Se092-Pe990-H8c72-V65aa-B11a8-R448a.deb Do you know whether we can use it instead?

Hi, I've got a Helios64 device running with OpenMediaVault 6.9.2-1 (Shaitan). kobol@helios64:~$ uname -a Linux helios64 6.1.50-current-rockchip64 #3 SMP PREEMPT Wed Aug 30 14:11:13 UTC 2023 aarch64 GNU/Linux It has been stable until I recently install openmediavault-photoprism 6.0.9-1 plugin provided by OMV6 through a podman container. I want to use PhotoPrism to help categorize my photos. The issue is my device systematically reboots during photo folder initial scan: the scan actually loads the system a lot, and in this state of activities, a reboot occurs after about 30 minutes to 4 hours. I first thought of a CPU temperature issue, it seems stabilized at about 64°C. But then, I caught the last journal entry before SSH disconnection: Oct 06 14:17:37 helios64 kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: Oct 06 14:17:37 helios64 kernel: rcu: 4-...0: (0 ticks this GP) idle=5b4c/1/0x4000000000000000 softirq=564112/564112 fqs=3016 Oct 06 14:17:37 helios64 kernel: (detected by 1, t=15005 jiffies, g=827657, q=216 ncpus=6) Oct 06 14:17:37 helios64 kernel: Task dump for CPU 4: Oct 06 14:17:37 helios64 kernel: task:photoprism state:R running task stack:0 pid:4761 ppid:4235 flags:0x00000802 Oct 06 14:17:37 helios64 kernel: Call trace: Oct 06 14:17:37 helios64 kernel: __switch_to+0xf0/0x170 Oct 06 14:17:37 helios64 kernel: 0xffff80001186bca8 Oct 06 14:17:37 helios64 kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: Oct 06 14:17:37 helios64 kernel: rcu: 4-...0: (0 ticks this GP) idle=5b4c/1/0x4000000000000000 softirq=564112/564112 fqs=12017 Oct 06 14:17:37 helios64 kernel: (detected by 3, t=60010 jiffies, g=827657, q=445 ncpus=6) Oct 06 14:17:37 helios64 kernel: Task dump for CPU 4: Oct 06 14:17:37 helios64 kernel: task:photoprism state:R running task stack:0 pid:4761 ppid:4235 flags:0x00000802 Oct 06 14:17:37 helios64 kernel: Call trace: Oct 06 14:17:37 helios64 kernel: __switch_to+0xf0/0x170 Oct 06 14:17:37 helios64 kernel: 0xffff80001186bca8 Oct 06 14:17:37 helios64 kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: Oct 06 14:17:37 helios64 kernel: rcu: 4-...0: (0 ticks this GP) idle=5b4c/1/0x4000000000000000 softirq=564112/564112 fqs=21018 Oct 06 14:17:37 helios64 kernel: (detected by 3, t=105015 jiffies, g=827657, q=681 ncpus=6) Oct 06 14:17:37 helios64 kernel: Task dump for CPU 4: Oct 06 14:17:37 helios64 kernel: task:photoprism state:R running task stack:0 pid:4761 ppid:4235 flags:0x00000802 Oct 06 14:17:37 helios64 kernel: Call trace: Oct 06 14:17:37 helios64 kernel: __switch_to+0xf0/0x170 Oct 06 14:17:37 helios64 kernel: 0xffff80001186bca8 So, I draw a link (possibly wrong) between PhotoPrism preempting the computing power, and the device shuting down. The system then starts again on watchdog signal and boots without issue. My last test was to have the system running with PhotoPrism plugin active, however without scanning activities. At this low workload, the system didn't reboot for the 4 days I let it. Have you got any clue on how I can confirm such preempt signal may cause a system shutdown?

Hi, According to the exchange on the thread below, adding the option --delete wasn't totally helpful. The thread refers to a change request on Github: https://github.com/armbian/build/pull/3779 As I understand, a fix is already applied on the source files. Fix details are discussed here: https://github.com/armbian/build/pull/3967 Specifically, additions and deletions on 3 files are detailed here: https://github.com/smlinux/armbian-tanix-tx6/commit/9087e8fd7158a06947fe5811232795451fb43f76 I've just checked the files on my system and they don't reflect the change yet on Github. So I've manually applied the change on my system: /etc/cron.d/armbian-truncate-logs Add this line at the end of the file: @reboot root /usr/lib/armbian/armbian-truncate-logs /usr/lib/armbian/armbian-ramlog Save the current version of the file, and deactivate it sudo mv /usr/lib/armbian/armbian-ramlog /usr/lib/armbian/armbian-ramlog.old sudo chmod -x /usr/lib/armbian/armbian-ramlog.old Create a new file /usr/lib/armbian/armbian-ramlog using Github details Activate the file sudo chmod +x /usr/lib/armbian/armbian-ramlog /usr/lib/armbian/armbian-truncate-logs Save the current version of the file, and deactivate it sudo mv /usr/lib/armbian/armbian-truncate-log /usr/lib/armbian/armbian-truncate-log.old sudo chmod -x /usr/lib/armbian/armbian-truncate-log.old Create a new file /usr/lib/armbian/armbian-truncate-log using Github details Activate the file sudo chmod +x /usr/lib/armbian/armbian-truncate-log I'll see whether it solves the issue...

Hi, I've got the same behavior using OpenMediaVault 6.0.21 on an Helios64 using Linux 5.15.25-rockchip64. I tried to extend /dev/zram1 size from 50M to 150M. # configuration values for the armbian-ram-logging service # # enable the armbian-ram-logging service? ENABLED=true # # size of the tmpfs mount -- please keep in mind to adjust /etc/default/armbian> SIZE=150M # # use rsync instead of cp -r # requires rsync installed, may provide better performance # due to copying only new and changed files USE_RSYNC=true kobol@helios64:~$ sudo zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram1 zstd 150M 16.4M 1.4M 3M 6 /var/log /dev/zram0 lzo-rle 1.9G 4K 74B 12K 6 [SWAP] After rebooting, /var/log size actually increased and the email flow stopped for a while. Until it reached a critical threshold I guess. So far, I've got one email per day saying the logs are truncated. However as I checked /var/log, it has plenty of room still. kobol@helios64:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 1.9G 0 1.9G 0% /dev tmpfs 387M 13M 374M 4% /run /dev/mmcblk1p1 15G 2.1G 12G 15% / tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 1.9G 0 1.9G 0% /tmp /dev/zram1 146M 17M 119M 13% /var/log /dev/md0 1.8T 772G 1.1T 43% /srv/dev-disk-by-uuid-835fd1cc-3d15-41e4-a782-d4a4b66a415a tmpfs 387M 0 387M 0% /run/user/1000 For info, please have below memory consumption of /var/log.hdd: kobol@helios64:~$ sudo du -h /var/log.hdd 12K /var/log.hdd/unattended-upgrades 180K /var/log.hdd/nginx 32K /var/log.hdd/salt 4.0K /var/log.hdd/samba/cores/nmbd 4.0K /var/log.hdd/samba/cores/smbd 12K /var/log.hdd/samba/cores 6.4M /var/log.hdd/samba 4.0K /var/log.hdd/watchdog 24K /var/log.hdd/cron-apt 32K /var/log.hdd/proftpd 4.0K /var/log.hdd/private 4.0K /var/log.hdd/chrony 4.0K /var/log.hdd/openmediavault 4.0K /var/log.hdd/sysstat 124K /var/log.hdd/apt 136M /var/log.hdd/journal/736dbda275634e9d985f9e5ae956b2a2 136M /var/log.hdd/journal 4.0K /var/log.hdd/runit/ssh 8.0K /var/log.hdd/runit 153M /var/log.hdd

Hi, as I read this post, I'm not certain whether this rk808 regulator issue is solved yet. For info, I'm currently running: kobol@helios64:~$ uname -a Linux helios64 5.10.63-rockchip64 #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021 aarch64 GNU/Linux and I have these logs (similar than @prahal for bad): kobol@helios64:~$ journalctl -b | grep regulator Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc1v8-sys-s0: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc0v9-s3: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage avdd-0v9-s0: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage avdd-1v8-s0: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage pcie-power: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc3v3-sys-s3: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc3v0-sd: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc5v0-usb: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage usblan-power: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: vdd_log: supplied by regulator-dummy Oct 30 14:47:58 helios64 kernel: rk808-regulator rk808-regulator: there is no dvs0 gpio Oct 30 14:47:58 helios64 kernel: rk808-regulator rk808-regulator: there is no dvs1 gpio Oct 30 14:47:58 helios64 kernel: rk808-regulator rk808-regulator: max buck steps per change: 4 Oct 30 14:47:58 helios64 kernel: rk808 0-001b: failed to register 12 regulator Oct 30 14:47:58 helios64 kernel: fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected! Oct 30 14:47:58 helios64 kernel: fan53555-regulator 0-0041: FAN53555 Option[8] Rev[1] Detected! Oct 30 14:47:58 helios64 kernel: rockchip-saradc ff100000.saradc: failed to get regulator, -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc1v8-sys-s0: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc0v9-s3: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage avdd-0v9-s0: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage avdd-1v8-s0: Failed to register regulator: -517 Oct 30 14:47:58 helios64 kernel: rk808-regulator rk808-regulator: there is no dvs0 gpio Oct 30 14:47:58 helios64 kernel: rk808-regulator rk808-regulator: there is no dvs1 gpio Oct 30 14:47:58 helios64 kernel: rk808-regulator rk808-regulator: max buck steps per change: 4 Oct 30 14:47:58 helios64 kernel: lm75 2-004c: supply vs not found, using dummy regulator Oct 30 14:47:58 helios64 systemd[1]: Starting fan speed regulator... Oct 30 14:47:59 helios64 systemd[1]: Started fan speed regulator. Does there already exist a fix for such up-to-date kernel? Regards,

For info, my MMC device includes 2 partitions. mmcblk2p1 includes /boot, and mmcblk2p2 contains linux folders. As I performed the steps above by mounting mmcblk2p2 on /mnt/system, new linux image 5.10.43 was actually available in /mnt/system/boot. However, I had to copy the files to mmcblk2p1 partition. Otherwise, my system starts on MMC without any change in linux version. After generated the image, I apply the instructions below: root@helios64:~# mkdir -p /mnt/boot root@helios64:~# mount /dev/mmcblk1p2 /mnt/boot root@helios64:~# cp -r /mnt/system/boot/* /mnt/boot/boot root@helios64:~# reboot