flower

Windows / Microsoft tried hard to kill GNU/Linux and F/LOSS for many years.  They don't deserve any Nice Things, IMO.  Let them die off already.
 
And ESXi is proprietary software.  Which also does not therefore deserve any community support, IMO.

Yes i'm running 5.9.11 since nearly two days and i can confirm that for now it seems way more stable than 5.8.14 / 5.8.17 (these two ones were constantly generating freezes). And without any changes like i2c overlays and still on SD card.
 
The amelioration is probably coming from the resolution of the issue i referenced a couple of posts below : https://armbian.atlassian.net/browse/AR-494

@jbergler I had the same issue with panics on 20.08.21 Buster (also using ZFS). Problem went away after I switched from ondemand to performance governor via armbian-config.

you can use the boot mode jumper to switch between eMMC (P10) and microSD (P11) boot, see the Helios wiki...
https://wiki.kobol.io/helios64/jumper/
 
 
@Helios Team...
what is the current image status?
Is it now possible to upgrade from 20.08.10 to the current version?
By now we are already at 20.08.22...
armbian-config/buster,buster 20.08.22 all [upgradable from: 20.08.10] armbian-firmware/buster,buster 20.08.22 all [upgradable from: 20.08.10] libfreetype6/stable,stable 2.9.1-3+deb10u2 arm64 [upgradable from: 2.9.1-3+deb10u1] libldap-2.4-2/stable,stable 2.4.47+dfsg-3+deb10u3 arm64 [upgradable from: 2.4.47+dfsg-3+deb10u2] libldap-common/stable,stable,stable,stable 2.4.47+dfsg-3+deb10u3 all [upgradable from: 2.4.47+dfsg-3+deb10u2] linux-buster-root-current-helios64/buster 20.08.21 arm64 [upgradable from: 20.08.10] linux-dtb-current-rockchip64/buster 20.08.21 arm64 [upgradable from: 20.08.10] linux-image-current-rockchip64/buster 20.08.21 arm64 [upgradable from: 20.08.10] linux-libc-dev/stable,stable 4.19.152-1 arm64 [upgradable from: 4.19.146-1] linux-u-boot-helios64-current/buster 20.08.21 arm64 [upgradable from: 20.08.10] openmediavault-omvextrasorg/buster,buster 5.4.2 all [upgradable from: 5.4.1] openmediavault/usul,usul,usul,usul 5.5.16-1 all [upgradable from: 5.5.12-1] salt-common/usul,usul,usul,usul 3002.1+ds-1 all [upgradable from: 3001.1+ds-1] salt-minion/usul,usul,usul,usul 3002.1+ds-1 all [upgradable from: 3001.1+ds-1] tzdata/stable-updates,stable-updates 2020d-0+deb10u1 all [upgradable from: 2020a-0+deb10u1]  

Soldering? No problem here !
I can help users from Germany to fix their helios board once the solution is released.

apt install glances
it also has a web interface - but it is resource intensive

On my system (kernel 5.8.17) a thread kworker/fusb302_wq was running, permanently eating 18% of one core, and causing the load average to be always at least 1.0. The module fusb30x could not be unloaded, rmmod just hung, although it's use count was zero. After blacklisting the module and rebooting the problem was solved.
Now is the question: what did I disable? Some googling gave me this document: 
So it has only to do with the USB-C port? The serial connection is still working fine.

oh sorry. i was confused and though you are talking about nc.

This afternoon (eg around 7h) i will put some smaller old disks in helios64 to keep an eye on the progress.

I can start those containers there again.

If you want me to provide any additional info just tell me.

As it will sit there with test data only i can give you root access too in case you are interested.

Gesendet von meinem CLT-L29 mit Tapatalk

This afternoon (eg around 7h) i will put some smaller old disks in helios64 to keep an eye on the progress.

I can start those containers there again.

If you want me to provide any additional info just tell me.

As it will sit there with test data only i can give you root access too in case you are interested.

Gesendet von meinem CLT-L29 mit Tapatalk

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

So, there was the new 20.08.16 today...
 
Someone test it? Same anouying bug that kill the server? I'm back to 20.08.10, that was the one that works for me...

Sadly buster.13 is still unstable. Got this after a few hours without much load. 
 
[ 8251.657645] ------------[ cut here ]------------
[ 8251.658075] kernel BUG at arch/arm64/kernel/traps.c:470!
[ 8251.658551] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 8251.659038] Modules linked in: iptable_nat iptable_filter bpfilter wireguard libchacha20poly1305 poly1305_neon ip6_udp_tunnel udp_tunnel libblake2s libcurve25519_generic libblake2s_generic veth xt_nat xt_tcpudp xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo nft_counter xt_addrtype nft_compat nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink br_netfilter bridge governor_performance zstd zram r8152 snd_soc_hdmi_codec snd_soc_rockchip_i2s leds_pwm snd_soc_core panfrost pwm_fan gpio_charger hantro_vpu(C) gpu_sched snd_pcm_dmaengine snd_pcm rockchip_vdec(C) rockchip_rga v4l2_h264 snd_timer videobuf2_dma_sg videobuf2_dma_contig snd rockchipdrm v4l2_mem2mem dw_mipi_dsi videobuf2_vmalloc videobuf2_memops dw_hdmi videobuf2_v4l2 soundcore analogix_dp videobuf2_common drm_kms_helper cec rc_core videodev fusb30x(C) gpio_beeper mc drm drm_panel_orientation_quirks sg cpufreq_dt lm75 ip_tables x_tables autofs4 raid456 async_raid6_recov async_memcpy
[ 8251.659153]  async_pq async_xor async_tx raid1 multipath linear raid10 raid0 md_mod realtek dwmac_rk stmmac_platform stmmac mdio_xpcs adc_keys
[ 8251.667928] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G         C        5.8.16-rockchip64 #20.08.13
[ 8251.668710] Hardware name: Helios64 (DT)
[ 8251.669062] pstate: 00000085 (nzcv daIf -PAN -UAO BTYPE=--)
[ 8251.669564] pc : do_undefinstr+0x2ec/0x310
[ 8251.669931] lr : do_undefinstr+0x1e0/0x310
[ 8251.670296] sp : ffff800011abbd50
[ 8251.670593] x29: ffff800011abbd50 x28: ffff0000f6ea5700 
[ 8251.671067] x27: ffff0000f6ea5700 x26: ffff800011abc000 
[ 8251.671540] x25: ffff8000114f1d20 x24: 0000000000000000 
[ 8251.672012] x23: 0000000040000085 x22: ffff800010df6d90 
[ 8251.672484] x21: ffff800011abbf00 x20: ffff0000f6ea5700 
[ 8251.672956] x19: ffff800011abbdc0 x18: 0000000000000000 
[ 8251.673428] x17: 0000000000000000 x16: 0000000000000000 
[ 8251.673900] x15: 0000000000000006 x14: 00000d554264da40 
[ 8251.674372] x13: 0000000000000322 x12: 000000000000036f 
[ 8251.674844] x11: 0000000000000001 x10: 0000000000000004 
[ 8251.675316] x9 : ffff0000f77a8590 x8 : ffff0000f77a7bc0 
[ 8251.675788] x7 : ffff0000f6211dc0 x6 : ffff800011abbda8 
[ 8251.676260] x5 : 00000000d5300000 x4 : ffff800011806118 
[ 8251.676731] x3 : 0000000034000000 x2 : 0000000000000002 
[ 8251.677203] x1 : ffff0000f6ea5700 x0 : 0000000040000085 
[ 8251.677676] Call trace:
[ 8251.677900]  do_undefinstr+0x2ec/0x310
[ 8251.678240]  el1_sync_handler+0x88/0x110
[ 8251.678591]  el1_sync+0x7c/0x100
[ 8251.678886]  check_preemption_disabled+0x30/0x108
[ 8251.679305]  __this_cpu_preempt_check+0x1c/0x34
[ 8251.679710]  irq_exit+0x70/0xe0
[ 8251.679996]  handle_IPI+0x25c/0x3e8
[ 8251.680312]  gic_handle_irq+0x154/0x158
[ 8251.680655]  el1_irq+0xb8/0x180
[ 8251.680938]  arch_cpu_idle+0x28/0x218
[ 8251.681269]  default_idle_call+0x1c/0x44
[ 8251.681622]  do_idle+0x210/0x288
[ 8251.681912]  cpu_startup_entry+0x28/0x68
[ 8251.682265]  secondary_start_kernel+0x140/0x178
[ 8251.682673] Code: f9401bf7 17ffff7d a9025bf5 f9001bf7 (d4210000) 
[ 8251.683223] ---[ end trace 47af1c5026823974 ]---
[ 8251.683636] Kernel panic - not syncing: Attempted to kill the idle task!
[ 8251.684232] SMP: stopping secondary CPUs
[ 8251.684588] Kernel Offset: disabled
[ 8251.684903] CPU features: 0x240022,2000600c
[ 8251.685275] Memory Limit: none
[ 8251.685562] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

80mm 2200rpm pwm
No i dont have a dust filter. 
 
This one https://www.heise.de/preisvergleich/noctua-nf-a8-pwm-a1165563.html

No this is not related to tx offloading. For now we still don't know why tx offloading needs to be disabled on LK5.8, while on LK4.4 it works without issue.

@aprayoga 
was once again very active, so we can look forward to further optimizations in the next armbian releases ...
 
https://github.com/armbian/build/commit/079b467342fffa7678f903793c589e9fe9fb8b69
https://github.com/armbian/build/commit/5e62c071f0c4bafd1d25ef5f5259bb485935a77e

Some of you had the problem that the back of the enclosure does not really fit and stuck a few mm to the outside - leading to loose usb cables.

I use noctua fans which are bigger and had the same problem since then.

I could solve it by putting that fan cage thingy outside and not inside the case.

Maybe it helps you too

Gesendet von meinem CLT-L29 mit Tapatalk

A little advice for anyone planning to use nand-sata-install to install on the eMMC and has already installed and configured OMV:
nand-sata-install will break OMV, but it's easy to fix if you know what's happening. It will skip /srv when copying the root to avoid copying stuff from other mounted filesystems, but OMV 5 stores part of its config in there (salt and pillar folders) and will throw a fit if they're not there when you boot from the eMMC. Simply copy these folders back from the microSD using your preferred method.
If you have NFS shares set in OMV, make sure to add the entry /export/* to the file /usr/lib/nand-sata-install/exclude.txt BEFORE running nand-sata-install, or it will try to copy the content of your NFS shares to the eMMC.
Lastly, if you're using ZFS, which by default mounts to /<pool_name>, make sure to add its mountpoint to /usr/lib/nand-sata-install/exclude.txt before nand-sata-install as well.

just donated a little.
thank you for this project!

if someone wants to shutdown their unit on powerloss:
 
create file: /etc/udev/rules.d/15-gpio-charger.rules
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="0", RUN+="/usr/sbin/halt"  
i'd love to know a way to start that unit when power is available again though.
 
on 4.4 the system crashes on halt. but as it does this after all services are stopped and the disks are synced this is not really a problem.
on 5.8 the system stops and "system halted" appears on serial console - BUT it is still on and fans are spinning.