Active threads

Seems it is an option for timer resolution in the measurement of duration. But the topic is about CPU usage precision returned by getrusage function. it is hardcoded interval of time when kernel updates CPU usage of particular thread/process.

Is this the changes ? I got still the same 😐

All Armbian board configurations files live in build/config/board/ Besides the Pcduino2 Cubieboard and OlinuXino-lime board, I don't know what other A10 boards still have some level of support. After that the next step would probably be to confirm that it works with uboot. Here you have another config file and dts. For any tweaks to uboot you will need to pass uboot-patch when running compile.sh. Note that when you do this you will need to open a new tab and navigate to cache/sources/u-boot-worktree/ Similiarly for the kernel you would navigate to cache/sources/kernel/ currently 6.12 is "current" while 6.14 is "edge" Hope this helps Ryzer

For production, boxes are much more interesting than boards. We just need to deal with a honest manufacturer. The last dtb from @mmie4jbcu worked very well for me in a x88 pro 20.

thank you for your help

That solves it thank you very much for your time! If I want to change between boards like Rockpro64, Raspberry Pi4, etc. is there anything that needs to be considered as far as "reset" to a fresh state. For the guide I am writing I would like to make sure there is no lingering configuration that could cause problems when switching between builds for different boards.

All things being equal....... steve@fedora43:~$ uname -a Linux fedora43 6.16.0-0.rc0.250528gfeacb1774bd5.5.fc43.aarch64 #1 SMP PREEMPT_DYNAMIC Wed May 28 19:45:02 UTC 2025 aarch64 GNU/Linux kernel-6.16.0-0.rc0.250529g90b83efa6701.6.fc43. created by jforbes 6 hours ago for Fedora 43 .

Hello. I wonder if this issue is connected to my issue - to show something on i2c, while there is nothing, and not be able to communicate on it ?

Beta repository. - should be on servers where we push on directly and this error can't occur (unless something broke down) - is the same quality as other Linux distributions (there is no other distro that would maintain those custom devices) - currently assembly is broken as some patches are failing and thus (beta) repo is not getting any updates until its fixed https://github.com/armbian/os/actions/runs/15337468717/job/43160986093

Since you are on current you cannot expect a major bump until the next LTS kernel is released. current will receive security fixes only. If you want something more recent you need to switch to edge kernels which follow non-LTS mainline kernel releases.

Hi Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

/_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v25.5.1 for Orange Pi Zero2W running Armbian Linux 6.12.23-current-sunxi64 Packages: Ubuntu stable (noble) Updates: Kernel upgrade enabled and 17 packages available for upgrade Support: DIY (community maintained) IPv4: (LAN) 192.168.***.***, 192.168.***.*** (WAN) ***.***.***.*** IPv6: *** Performance: Load: 11% Up time: 4 min Local users: 3 Memory usage: 24% of 1.93G CPU temp: 45°C Usage of /: 10% of 58G Commands: Configuration : armbian-config Upgrade : armbian-upgrade Monitoring : htop orangepi@orangepizero2w:~$ It boots into xfce wifi works, eth works and hdmi work. 2gb board with keyboard plugged into expansion board.

@remolaan I think this is the most current info that may help you:

I own a CM3588 NAS board from FriendlyElec. The eMMC drive was factory-installed with the FriendlyElec version of OpenMediaVault, and any other FriendlyElec or Armbian image could be booted from an SD card. After installing the current version of Armbian OpenMediaVault (Debian 12 Bookworm - Armbian Linux v6.1 Build Date: Mar 6, 2025) on eMMC and updating bootloader via armbian-config (option Boot from eMMC + system on eMMC), nothing else can be booted from the SD card except Armbian images. Please, is there a simple way to fix bootloader back to original option of booting FriendlyElec images from SD card without having to erase entire eMMC drive? Boot from SD card does not work even for FriendlyElec automatic eflasher (SD to eMMC) images. I have Windows 11 and RKDevTool 3.30 is quite confusing and too complex software for me. PS. Does the CM3588 NAS board have SPI NOR flash? And how can I upload UEFI 1.1 boot (https://github.com/edk2-porting/edk2-rk3588) to eMMC or to SPI NOR?

Hello again, I am struggling to install armbian on my H96Max (blue PCB RK3318_V1.4, 4G/64G). The Armbian_22.11.0-trunk_Rk3318-box_bullseye_edge_5.19.15_minimal.img image works OK (at least for the display). All the new images fail to initialise the display (a 4K HDMI monitor), either using *_minimal.img or *_gnome_desktop.img I managed to install the latest (Armbian_community_25.8.0-trunk.8_Rk3318-box_noble_current_6.12.28_gnome_desktop.img) image using the serial console. Kernel is 6.12.28 I can now connect using ssh on ethernet (the WIFI does not work yet...) I get in syslog and dmesg a LOT of the following errors: [ 2683.281403] ------------[ cut here ]------------ [ 2683.281441] [CRTC:38:crtc-0] vblank wait timed out [ 2683.281570] WARNING: CPU: 1 PID: 50 at drivers/gpu/drm/drm_atomic_helper.c:1682 drm_atomic_helper_wait_for_vblanks.part.0+0x238/0x25c [ 2683.281629] Modules linked in: cfg80211 rfcomm algif_hash algif_skcipher af_alg bnep sunrpc snd_soc_hdmi_codec hci_uart btqca hantro_vpu btrtl btintel crct10dif_ce rockchip_vdec(C) v4l2_jpeg v4l2_vp9 btbcm rockchip_rga v4l2_h264 bluetooth videobuf2_dma_contig snd_soc_spdif_tx gpio_ir_recv videobuf2_dma_sg rc_core v4l2_mem2mem rfkill videobuf2_memops videobuf2_v4l2 dw_hdmi_i2s_audio videodev dw_hdmi_cec lima snd_soc_simple_card videobuf2_common snd_soc_rockchip_spdif snd_soc_rockchip_i2s snd_soc_rk3328 snd_soc_simple_card_utils gpu_sched drm_shmem_helper mc snd_soc_core rk_crypto snd_compress rng_core snd_pcm_dmaengine snd_pcm snd_timer snd soundcore cpufreq_dt joydev zram zsmalloc binfmt_misc sch_fq_codel dm_mod autofs4 dwmac_rk stmmac_platform stmmac pcs_xpcs nvmem_rockchip_efuse rockchipdrm dw_hdmi_qp gpio_syscon dw_hdmi cec dw_mipi_dsi analogix_dp drm_display_helper adc_keys [ 2683.282340] CPU: 1 UID: 0 PID: 50 Comm: kworker/u16:2 Tainted: G B WC 6.12.28-current-rockchip64 #1 [ 2683.282375] Tainted: [B]=BAD_PAGE, [W]=WARN, [C]=CRAP [ 2683.282389] Hardware name: Rockchip RK3318 BOX (DT) [ 2683.282409] Workqueue: events_unbound commit_work [ 2683.282446] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2683.282471] pc : drm_atomic_helper_wait_for_vblanks.part.0+0x238/0x25c [ 2683.282499] lr : drm_atomic_helper_wait_for_vblanks.part.0+0x238/0x25c [ 2683.282531] sp : ffff8000809dbcb0 [ 2683.282542] x29: ffff8000809dbce0 x28: 00000000000007d5 x27: 0000000000000000 [ 2683.282580] x26: 0000000000000001 x25: 0000000000000000 x24: ffff6d33cdf68000 [ 2683.282616] x23: 0000000000000001 x22: 0000000000000000 x21: ffff6d33cc6f6280 [ 2683.282654] x20: ffff6d33cdf70080 x19: 0000000000000000 x18: ffffffffffffffff [ 2683.282691] x17: 000000040044ffff x16: 00500072b5503510 x15: ffff8000809db860 [ 2683.282727] x14: 00000000ffffffea x13: ffff8000809db9f8 x12: ffffd4f64aa4ac10 [ 2683.282768] x11: 0000000000032030 x10: 0000000000031fe0 x9 : 0000000000024330 [ 2683.282805] x8 : c0000000fffff822 x7 : ffffd4f64a99aa18 x6 : 0000000000084bb0 [ 2683.282842] x5 : ffff6d34be7424c8 x4 : 0000000000000000 x3 : 0000000000000027 [ 2683.282878] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff6d33c4c4c600 [ 2683.282918] Call trace: [ 2683.282932] drm_atomic_helper_wait_for_vblanks.part.0+0x238/0x25c [ 2683.282962] drm_atomic_helper_commit_tail_rpm+0x84/0xa0 [ 2683.282992] commit_tail+0xa4/0x18c [ 2683.283019] commit_work+0x14/0x20 [ 2683.283043] process_one_work+0x16c/0x3e4 [ 2683.283073] worker_thread+0x2d0/0x3d8 [ 2683.283097] kthread+0x10c/0x110 [ 2683.283123] ret_from_fork+0x10/0x20 [ 2683.283151] ---[ end trace 0000000000000000 ]--- This seems to come from the accelerated graphic driver. The corresponding function can be seen there: drm_atomic_helper.c This function waits for receiving a vertical blanking pulse that never comes, so the warning at line 1679 is triggered. I don't intend to do hard-core graphics so I don't care about graphic performance. In fact this lovely box will be used for hosting a headless server. Is there a way to use a legacy or un-accelerated graphic driver? If not, how could I remove entirely the graphic subsystem and use only character mode? Thanks! Michel EDIT: In fact the first warning occurs when switching to the colour frame buffer device: ... rk_gmac-dwmac ff550000.ethernet: Enable RX Mitigation via HW Watchdog Timer May 29 19:00:08 h96max kernel: rk_gmac-dwmac ff550000.ethernet: device MAC address de:10:75:60:c0:cb May 29 19:00:08 h96max kernel: Console: switching to colour frame buffer device 160x45 May 29 19:00:08 h96max kernel: ------------[ cut here ]------------ May 29 19:00:08 h96max kernel: [CRTC:38:crtc-0] vblank wait timed out May 29 19:00:08 h96max kernel: WARNING: CPU: 0 PID: 74 at drivers/gpu/drm/drm_atomic_helper.c:1682 drm_atomic_helper_wait_for_vblanks.part.0+0x238/0x25c May 29 19:00:08 h96max kernel: Modules linked in: dwmac_rk stmmac_platform stmmac pcs_xpcs nvmem_rockchip_efuse gpio_syscon rockchipdrm dw_hdmi_qp dw_hdmi cec dw_mipi_dsi analogix_dp drm_display_helper adc_keys May 29 19:00:08 h96max kernel: CPU: 0 UID: 0 PID: 74 Comm: kworker/u16:5 Tainted: G B 6.12.28-current-rockchip64 #1 May 29 19:00:08 h96max kernel: Tainted: [B]=BAD_PAGE ... So I suspect that not switching to a FB could solve my problem

👍 Thanks!

Great news and thank you for reporting back. Do you have any idea what they changed or where they host their sources so we can have a look? There is for example this. There is another user who reported running into problems that sounded a lot like yours.

Hi, wake-on-lan should be working now due to https://github.com/armbian/build/pull/8235. Groetjes,

After cleaning up and expanding Whisper-Hindi to 3,000 hours, we now have explicit timestamp prediction, faster I/O, and fine-tuned models across all sizes, bringing us even closer to fully reliable, production-ready Hindi ASR. View the full article

Thanks Igor for your work!

looks like a really cool machine. unfortunately, no maintainer in armbian and I am not aware if any of the regular developpers has that SBC. It seems to be based on the H618 which it shares with the Orange Pi Zero3 which is reported working with the latest Armbian release. Did this board ever work with an older release? Is this a regression? I see somebody else mentioning they have issues with the board booting, , apparently due to issues with thermal management. And your crash apparently started in pstate.

Nice. To help other users of the forum, it would be good if you shared what fixed the issue.

To be honest, I'm confused. You reference three different systems and it is unclear to me which one it is that FTBFS for you. Let's take a step back. Do you have the latest git tree of armbian/build? Do you have any local changes? What is the exact command you for compile.sh? I will try to reproduce the problem here.

Sparking between the wires on the poles produces high-frequency pulses of high power and transmits them through the wires to consumers of electricity. Household consumers such as a TV, vacuum cleaner, refrigerator do not have a built-in high-frequency protection filter and very often fail. As for the orange, it is not protected at all. My orange was just lying on the table and was connected by an Ethernet cable to the router. Both were not power up. Lightning struck a nearby building. The Ethernet cable caught an electromagnetic pulse. The orange burned down completely and the router has only 1 port damaged. You can draw your own conclusions.

This mode needs 80MHz pixel clock which is not in the table for clk-rk3568.c driver. You need a patch similar to https://lkml.org/lkml/2025/3/18/1337 to add this rate. FWIW 1280x800@63.59Hz isn't a very common mode