Trillien
-
Posts
23 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by 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: 48msI 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
-
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: 0I 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
-
Quote
could be due to the commands after the installation...
line 345-347 omv-confdbadm populate 2>&1 | tee -a ${logfile} omv-salt deploy run hosts 2>&1 | tee -a ${logfile} fiNop, 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-configNeeded 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 bashTo 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.oldCreate 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.oldCreate a new file /usr/lib/armbian/armbian-truncate-log using Github details
Activate the file
sudo chmod +x /usr/lib/armbian/armbian-truncate-logI'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
-
On 9/16/2021 at 3:08 AM, prahal said:
bisected eMMC breakage:
06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66 is the first bad commit
commit 06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66 Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Date: Thu May 20 01:12:23 2021 +0300 regulator: core: resolve supply for boot-on/always-on regulators commit 98e48cd9283dbac0e1445ee780889f10b3d1db6a upstream. For the boot-on/always-on regulators the set_machine_constrainst() is called before resolving rdev->supply. Thus the code would try to enable rdev before enabling supplying regulator. Enforce resolving supply regulator before enabling rdev. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210519221224.2868496-1-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> drivers/regulator/core.c | 6 ++++++ 1 file changed, 6 insertions(+)is https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/regulator/core.c?id=98e48cd9283dbac0e1445ee780889f10b3d1db6a
from thread https://lore.kernel.org/all/20210519221224.2868496-1-dmitry.baryshkov@linaro.org/diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 7b3de8b0b1ca..043b5f63b94a 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -1422,6 +1422,12 @@ static int set_machine_constraints(struct regulator_dev *rdev) * and we have control then make sure it is enabled. */ if (rdev->constraints->always_on || rdev->constraints->boot_on) { + /* If we want to enable this regulator, make sure that we know + * the supplying regulator. + */ + if (rdev->supply_name && !rdev->supply) + return -EPROBE_DEFER; + if (rdev->supply) { ret = regulator_enable(rdev->supply); if (ret < 0) {
EDIT 1: this change to return EPROBE_DEFER if regulator has a supply name but no supply ready was intended to complete commit aea6cb99703e17019e025aa71643b4d3e0a24413 which expects set_machine_constraints to return this eprobe_defer error to attempt to resolve the supply ( before attempting a second run of set_machine_constraints).
One still need to find out if aea6cb99703e17019e025aa71643b4d3e0a24413 fails to resolve the supply and thus does not make a second attempt to set_machine_constraints thus leaves the regulator disabled or else.
commit aea6cb99703e17019e025aa71643b4d3e0a24413 Author: Micha? Miros?aw <mirq-linux@rere.qmqm.pl> Date: Sat Sep 26 23:32:41 2020 +0200 regulator: resolve supply after creating regulator When creating a new regulator its supply cannot create the sysfs link because the device is not yet published. Remove early supply resolving since it will be done later anyway. This makes the following error disappear and the symlinks get created instead. DCDC_REG1: supplied by VSYS VSYS: could not add device link regulator.3 err -2 Note: It doesn't fix the problem for bypassed regulators, though. Fixes: 45389c47526d ("regulator: core: Add early supply resolution for regulators") Signed-off-by: Micha? Miros?aw <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/ba09e0a8617ffeeb25cb4affffe6f3149319cef8.1601155770.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index ff8e99ca0306..9f704a6c4802 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -5280,15 +5280,20 @@ regulator_register(const struct regulator_desc *regulator_desc, else if (regulator_desc->supply_name) rdev->supply_name = regulator_desc->supply_name; - /* - * Attempt to resolve the regulator supply, if specified, - * but don't return an error if we fail because we will try - * to resolve it again later as more regulators are added. - */ - if (regulator_resolve_supply(rdev)) - rdev_dbg(rdev, "unable to resolve supply\n"); - ret = set_machine_constraints(rdev, constraints); + if (ret == -EPROBE_DEFER) { + /* Regulator might be in bypass mode and so needs its supply + * to set the constraints */ + /* FIXME: this currently triggers a chicken-and-egg problem + * when creating -SUPPLY symlink in sysfs to a regulator + * that is just being created */ + ret = regulator_resolve_supply(rdev); + if (!ret) + ret = set_machine_constraints(rdev, constraints); + else + rdev_dbg(rdev, "unable to resolve supply early: %pe\n", + ERR_PTR(ret)); + } if (ret < 0) goto wash;
My logs for bad shows:
[ 1.257297] reg-fixed-voltage vcc1v8-sys-s0: Failed to register regulator: -517 [ 1.257446] reg-fixed-voltage vcc0v9-s3: Failed to register regulator: -517 [ 1.257588] reg-fixed-voltage avdd-0v9-s0: Failed to register regulator: -517 [ 1.257728] reg-fixed-voltage avdd-1v8-s0: Failed to register regulator: -517 [ 1.258114] reg-fixed-voltage pcie-power: Failed to register regulator: -517 [ 1.258312] reg-fixed-voltage vcc3v3-sys-s3: Failed to register regulator: -517 [ 1.258451] reg-fixed-voltage vcc3v0-sd: Failed to register regulator: -517 [ 1.258705] reg-fixed-voltage vcc5v0-usb: Failed to register regulator: -517 [ 1.261721] reg-fixed-voltage usblan-power: Failed to register regulator: -517 [ 2.158719] vdd_log: supplied by regulator-dummy [ 2.230749] rk808-regulator rk808-regulator: there is no dvs0 gpio [ 2.230781] rk808-regulator rk808-regulator: there is no dvs1 gpio [ 2.230792] rk808-regulator rk808-regulator: max buck steps per change: 4 [ 2.240854] rk808 0-001b: failed to register 12 regulator [ 2.249848] fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected! [ 2.253127] fan53555-regulator 0-0041: FAN53555 Option[8] Rev[1] Detected! [ 2.423549] reg-fixed-voltage vcc1v8-sys-s0: Failed to register regulator: -517 [ 2.424263] reg-fixed-voltage vcc0v9-s3: Failed to register regulator: -517 [ 2.424830] reg-fixed-voltage avdd-0v9-s0: Failed to register regulator: -517 [ 2.425443] reg-fixed-voltage avdd-1v8-s0: Failed to register regulator: -517 [ 2.556287] rk808-regulator rk808-regulator: there is no dvs0 gpio [ 2.556318] rk808-regulator rk808-regulator: there is no dvs1 gpio [ 2.556328] rk808-regulator rk808-regulator: max buck steps per change: 4
while for good:
[ 2.172993] vdd_log: supplied by regulator-dummy [ 2.330040] rk808-regulator rk808-regulator: there is no dvs0 gpio [ 2.330071] rk808-regulator rk808-regulator: there is no dvs1 gpio [ 2.330081] rk808-regulator rk808-regulator: max buck steps per change: 4 [ 2.347345] fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected! [ 2.350525] fan53555-regulator 0-0041: FAN53555 Option[8] Rev[1] Detected!
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/Linuxand 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,
-
On 9/1/2021 at 5:08 PM, TDCroPower said:
It worked, I have my eMMC system back!
Here are all the steps in case someone else has the problem and wants to repair his eMMC image...
1. download a previous Helios64 image from here...
https://wiki.kobol.io/download/
2. install the image on a microSD e.g. for Windows and macOS there is Etcher...
https://www.balena.io/etcher/
3a. boot your Helios64 with the microSD and Jumper 10, see here...
https://wiki.kobol.io/helios64/troubleshoot/#how-to-force-boot-from-microsd
3b. Alternative: from the serial console press a key on the keyboard while u-boot start. You will get the u-boot prompt.From this prompt write and press enter. Helios64 will boot from SD... (thx @prahal)
run bootcmd_mmc14. if you are logged in as root user (normal users must put a sudo in front of the commands) execute the following commands...
root@helios64:~# mkdir -p /mnt/system root@helios64:~# mount /dev/mmcblk2p1 /mnt/system root@helios64:~# cd /mnt/system/
5. The contents of the /mnt/system directory should now be filled with the contents of your eMMC....root@helios64:/mnt/system# ll total 80 lrwxrwxrwx 1 root root 7 Aug 30 2020 bin -> usr/bin drwxr-xr-x 3 root root 4096 Sep 1 03:01 boot drwxr-xr-x 2 root root 4096 Oct 15 2020 dev drwxr-xr-x 110 root root 12288 Sep 1 03:01 etc drwxr-xr-x 2 root root 4096 Sep 22 2020 export drwxr-xr-x 5 root root 4096 Jun 10 04:12 home lrwxrwxrwx 1 root root 7 Aug 30 2020 lib -> usr/lib drwx------ 5 root root 4096 Oct 5 2020 lost+found drwxr-xr-x 4 root root 4096 Oct 15 2020 media drwxr-xr-x 2 root root 4096 Feb 9 2021 mnt drwxr-xr-x 4 root root 4096 Dec 2 2020 opt dr-xr-xr-x 2 root root 4096 Oct 15 2020 proc drwx------ 7 root root 4096 Aug 31 23:36 root drwxr-xr-x 2 root root 4096 Oct 15 2020 run lrwxrwxrwx 1 root root 8 Aug 30 2020 sbin -> usr/sbin drwxrwxr-x 2 root root 4096 Oct 5 2020 selinux drwxr-xr-x 6 root root 4096 Jun 10 03:18 srv dr-xr-xr-x 2 root root 4096 Oct 15 2020 sys lrwxrwxrwx 1 root root 42 Sep 1 03:01 thermal_zone0 -> /sys/devices/virtual/thermal/thermal_zone0 drwxrwxrwt 2 root root 4096 Oct 15 2020 tmp drwxr-xr-x 12 root root 4096 Nov 27 2020 usr drwxr-xr-x 14 root root 4096 Oct 6 2020 var
6. now download the 3 old packages...
root@helios64:/mnt/system# wget http://armbian.hosthatch.com/apt/pool/main/l/linux-5.10.43-rockchip64/linux-dtb-current-rockchip64_21.05.4_arm64.deb root@helios64:/mnt/system# wget http://armbian.hosthatch.com/apt/pool/main/l/linux-5.10.43-rockchip64/linux-headers-current-rockchip64_21.05.4_arm64.deb root@helios64:/mnt/system# wget http://armbian.hosthatch.com/apt/pool/main/l/linux-5.10.43-rockchip64/linux-image-current-rockchip64_21.05.4_arm64.deb
7. now changes the root directory...
root@helios64:/mnt/system# chroot /mnt/system root@helios64:/# pwd / root@helios64:/# ll total 50996 lrwxrwxrwx 1 root root 7 Aug 30 2020 bin -> usr/bin drwxr-xr-x 3 root root 4096 Sep 1 14:56 boot drwxr-xr-x 2 root root 4096 Sep 1 16:15 dev drwxr-xr-x 110 root root 12288 Sep 1 03:01 etc drwxr-xr-x 2 root root 4096 Sep 22 2020 export drwxr-xr-x 5 root root 4096 Jun 10 04:12 home lrwxrwxrwx 1 root root 7 Aug 30 2020 lib -> usr/lib -rw-r--r-- 1 root root 314304 Jul 8 19:32 linux-dtb-current-rockchip64_21.05.4_arm64.deb -rw-r--r-- 1 root root 11527696 Jul 8 19:32 linux-headers-current-rockchip64_21.05.4_arm64.deb -rw-r--r-- 1 root root 40290884 Jul 8 19:33 linux-image-current-rockchip64_21.05.4_arm64.deb drwx------ 5 root root 4096 Oct 5 2020 lost+found drwxr-xr-x 4 root root 4096 Oct 15 2020 media drwxr-xr-x 2 root root 4096 Feb 9 2021 mnt drwxr-xr-x 4 root root 4096 Dec 2 2020 opt dr-xr-xr-x 2 root root 4096 Oct 15 2020 proc drwx------ 7 root root 4096 Aug 31 23:36 root drwxr-xr-x 2 root root 4096 Oct 15 2020 run lrwxrwxrwx 1 root root 8 Aug 30 2020 sbin -> usr/sbin drwxrwxr-x 2 root root 4096 Oct 5 2020 selinux drwxr-xr-x 6 root root 4096 Jun 10 03:18 srv dr-xr-xr-x 2 root root 4096 Oct 15 2020 sys lrwxrwxrwx 1 root root 42 Sep 1 03:01 thermal_zone0 -> /sys/devices/virtual/thermal/thermal_zone0 drwxrwxrwt 2 root root 4096 Oct 15 2020 tmp drwxr-xr-x 12 root root 4096 Nov 27 2020 usr drwxr-xr-x 14 root root 4096 Oct 6 2020 var
8. now installs the downloaded packages...
root@helios64:/# dpkg -i *.deb dpkg: warning: downgrading linux-dtb-current-rockchip64 from 21.08.1 to 21.05.4 (Reading database ... 62558 files and directories currently installed.) Preparing to unpack linux-dtb-current-rockchip64_21.05.4_arm64.deb ... Unpacking linux-dtb-current-rockchip64 (21.05.4) over (21.08.1) ... Selecting previously unselected package linux-headers-current-rockchip64. Preparing to unpack linux-headers-current-rockchip64_21.05.4_arm64.deb ... Unpacking linux-headers-current-rockchip64 (21.05.4) ... dpkg: warning: downgrading linux-image-current-rockchip64 from 21.08.1 to 21.05.4 Preparing to unpack linux-image-current-rockchip64_21.05.4_arm64.deb ... update-initramfs: Deleting /boot/initrd.img-5.10.60-rockchip64 Removing obsolete file uInitrd-5.10.60-rockchip64 stat: cannot stat '/proc/1/root/.': No such file or directory Unpacking linux-image-current-rockchip64 (21.05.4) over (21.08.1) ... Setting up linux-dtb-current-rockchip64 (21.05.4) ... Setting up linux-headers-current-rockchip64 (21.05.4) ... Compiling headers - please wait ... grep: /proc/cpuinfo: No such file or directory grep: /proc/cpuinfo: No such file or directory Setting up linux-image-current-rockchip64 (21.05.4) ... update-initramfs: Generating /boot/initrd.img-5.10.43-rockchip64 W: Couldn't identify type of root file system for fsck hook update-initramfs: Converting to u-boot format
9. reset the root change with exit and restart your helios64 with reboot...
root@helios64:/# exit exit root@helios64:/mnt/system# reboot
10. after a reboot you should now boot from the eMMC again...
root@192.168.180.5's password: _ _ _ _ __ _ _ | | | | ___| (_) ___ ___ / /_ | || | | |_| |/ _ \ | |/ _ \/ __| '_ \| || |_ | _ | __/ | | (_) \__ \ (_) |__ _| |_| |_|\___|_|_|\___/|___/\___/ |_| Welcome to Armbian 21.08.1 Buster with Linux 5.10.43-rockchip64 No end-user support: built from trunk System load: 74% Up time: 3 min Memory usage: 34% of 3.77G IP: 172.18.0.1 172.19.0.1 172.20.0.1 172.17.0.1 192.168.180.5 CPU temp: 66°C Usage of /: 87% of 15G [ 0 security updates available, 3 updates total: apt upgrade ] Last check: 2021-09-01 16:38 [ General system configuration (beta): armbian-config ] Last login: Wed Sep 1 16:26:23 2021 root@helios64:~# root@helios64:~# uname -a Linux helios64 5.10.43-rockchip64 #21.05.4 SMP PREEMPT Wed Jun 16 08:02:12 UTC 2021 aarch64 GNU/Linux root@helios64:~#
11. if the eMMC was used you can see with mount...
root@helios64:~# mount | grep /dev/mmc /dev/mmcblk2p1 on / type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600) /dev/mmcblk2p1 on /var/folder2ram/var/log type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600) /dev/mmcblk2p1 on /var/folder2ram/var/tmp type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600) /dev/mmcblk2p1 on /var/folder2ram/var/lib/openmediavault/rrd type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600) /dev/mmcblk2p1 on /var/folder2ram/var/spool type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600) /dev/mmcblk2p1 on /var/folder2ram/var/lib/rrdcached type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600) /dev/mmcblk2p1 on /var/folder2ram/var/lib/monit type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600) /dev/mmcblk2p1 on /var/folder2ram/var/cache/samba type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600)
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
Helios64 u-boot does not build anymore after we bumped to 2022.07
in Rockchip
Posted
I've just tested cpufreq-switching-2-delay5msec in emergency mode.
My setup is Armbian 23.08.0-trunk Bookworm with Linux 6.6.8-edge-rockchip64
My first attempt ran for few minutes before freezing and rebooting.
Before my second attempt, I blacklist panfrost (not sure there is an impact at all in emergency mode...)
$ sudo nano /etc/modprobe.d/blacklist.conf blacklist panfrostI then rebooted and started linux in emergency mode.
# lsmod | grep panfrostlsmod didn't catch any panfrost module.
Still, cpufreq-switching-2-delay5msec ended with a kernel panic:
10/100 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 cpub_freq 1416000 cpub_freq 1200000 cpub_freq 1008000 cpub_freq 816000 cpub_freq 600000 cpub_freq 408000 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 cpub_freq 1416000 cpub_freq 1200000 cpub_freq 1008000 cpub_freq 816000 cpub_freq 600000 cpub_freq 408000 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 cpub_freq 1416000 cpub_freq 1200000 cpub_freq 1008000 cpub_freq 816000 cpub_freq 600000 cpub_freq 408000 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 cpub_freq 1416000 cpub_freq 1200000 cpub_freq 1008000 cpub_freq 816000 cpub_freq 600000 cpub_freq 408000 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 cpub_freq 1416000 cpub_freq 1200000 cpub_freq 1008000 cpub_freq 816000 cpub_freq 600000 cpub_freq 408000 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 cpub_freq 1416000 cpub_freq 1200000 cpub_freq 1008000 cpub_freq 816000 cpub_freq 600000 cpub_freq 408000 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 [ 51.732314] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP [ 51.732887] Modules linked in: ip_tables x_tables autofs4 efivarfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid0 multipath linear cdc_ncm cdc_ether usbnet raid1 r8152 realtek rockchipdrm dw_mipi_dsi dw_hdmi analogix_dp fusb302 drm_display_helper cec tcpm drm_dma_helper typec drm_kms_helper dwmac_rk stmmac_platform stmmac drm pcs_xpcs adc_keys [ 51.735962] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 6.6.8-edge-rockchip64 #1 [ 51.736610] Hardware name: Helios64 (DT) [ 51.736965] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 51.737589] pc : update_blocked_averages+0x278/0x758 [ 51.738051] lr : update_blocked_averages+0x264/0x758 [ 51.738504] sp : ffff800082043e80 [ 51.738806] x29: ffff800082043e80 x28: ffff000005cd9600 x27: 0000000c01b0a9aa [ 51.739456] x26: ffff000005cdbc80 x25: ffff000005cdbc00 x24: 0000000000000000 [ 51.740104] x23: ffff0000f77a0f18 x22: 0000000000000028 x21: 0000000000000000 [ 51.740750] x20: ffff000005cdbd40 x19: ffff0000f77a05c0 x18: 0000000000000000 [ 51.741396] x17: ffff800075e85000 x16: ffff800082040000 x15: 0000000000000000 [ 51.742043] x14: 0000000000000001 x13: 000000000000002a x12: 00000000000e7fe0 [ 51.742689] x11: 0000000000000000 x10: 000000000000002a x9 : ffff000005cdbc80 [ 51.743336] x8 : 0000000000000000 x7 : ffff000005cdbc00 x6 : 0000000000000014 [ 51.743982] x5 : 00000000000003af x4 : 000000000000b6a8 x3 : 0000000000000000 [ 51.744628] x2 : 0000000000000000 x1 : ffff000001d6c400 x0 : ffff0000019c6000 [ 51.745274] Call trace: [ 51.745501] update_blocked_averages+0x278/0x758 [ 51.745924] run_rebalance_domains+0x4c/0x80 [ 51.746313] __do_softirq+0x160/0x3fc [ 51.746649] ____do_softirq+0x10/0x1c [ 51.746985] call_on_irq_stack+0x24/0x4c [ 51.747344] do_softirq_own_stack+0x1c/0x2c [ 51.747727] irq_exit_rcu+0x94/0xd0 [ 51.748051] el1_interrupt+0x38/0x68 [ 51.748382] el1h_64_irq_handler+0x18/0x24 [ 51.748758] el1h_64_irq+0x64/0x68 [ 51.749070] cpuidle_enter_state+0xc0/0x4bc [ 51.749454] cpuidle_enter+0x38/0x50 [ 51.749783] do_idle+0x1fc/0x270 [ 51.750083] cpu_startup_entry+0x34/0x3c [ 51.750444] secondary_start_kernel+0x128/0x148 [ 51.750859] __secondary_switched+0xb8/0xbc [ 51.751249] Code: f940ab20 f9406400 f8766801 b4000101 (f9407020) [ 51.751797] ---[ end trace 0000000000000000 ]--- [ 51.752214] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 51.752826] SMP: stopping secondary CPUs [ 51.753358] Kernel Offset: disabled [ 51.753674] CPU features: 0x1,00000208,3c020000,1000421b [ 51.754152] Memory Limit: none [ 51.754439] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---