All Activity

It was a network problem. Problem fixed after global activation of a clash proxy. Thanks a lot!

Starting kernel ... [ 11.131621] Kernel panic - not syncing: panic_on_set_idle set ... [ 11.132177] CPU: 1 PID: 47 Comm: kworker/u8:3 Not tainted 6.1.115-vendor-rk35xx #1 [ 11.132851] Hardware name: PinusCore RK3562 (DT) [ 11.133272] Workqueue: events_unbound async_run_entry_fn [ 11.133760] Call trace: [ 11.133986] dump_backtrace+0xe8/0x124 [ 11.134332] show_stack+0x20/0x30 [ 11.134641] dump_stack_lvl+0x6c/0x88 [ 11.134975] dump_stack+0x18/0x34 [ 11.135283] panic+0x138/0x310 [ 11.135573] rockchip_pmu_set_idle_request+0x114/0x1d8 [ 11.136043] rockchip_pd_power+0x424/0x480 [ 11.136419] rockchip_pd_power_on+0x24/0x38 [ 11.136798] _genpd_power_on+0xbc/0x150 [ 11.137154] genpd_power_on+0x5c/0x14c [ 11.137500] __genpd_dev_pm_attach+0x1ac/0x280 [ 11.137903] genpd_dev_pm_attach+0x68/0x6c [ 11.138281] dev_pm_domain_attach+0x20/0x3c [ 11.138660] platform_probe+0x58/0xc0 [ 11.138992] really_probe+0x1cc/0x390 [ 11.139326] __driver_probe_device+0x140/0x158 [ 11.139729] driver_probe_device+0x44/0x100 [ 11.140108] __device_attach_driver+0x110/0x124 [ 11.140520] bus_for_each_drv+0xa8/0xd4 [ 11.140876] __device_attach_async_helper+0x7c/0xf8 [ 11.141322] async_run_entry_fn+0x6c/0x14c [ 11.141698] process_one_work+0x1b8/0x268 [ 11.142065] worker_thread+0x1e8/0x254 [ 11.142409] kthread+0xc0/0xd0 [ 11.142697] ret_from_fork+0x10/0x20 [ 11.143029] SMP: stopping secondary CPUs [ 11.143382] CPU2: stopping [ 11.143382] CPU3: stopping [ 3382] CPU0: stopping [ 11.143385] CPU: 2 PID: 9 Comm: kworker/u8:0 Not tainted 6.1.115-vendor-rk35xx #1 [ 11.143390] Hardware name: PinusCore RK3562 (DT) [ 11.143393] Workqueue: events_unbound deferred_probe_work_func [ 11.143401] Call trace: [ 11.143402] dump_backtrace+0xe8/0x124 [ 11.143408] show_stack+0x20/0x30 [ 11.143413] dump_stack_lvl+0x6c/0x88 [ 11.143418] dump_stack+0x18/0x34 [ 11.143423] local_cpu_stop+0x4c/0x6c [ 11.143428] ipi_handler+0xe0/0x1d0 [ 11.143433] handle_percpu_devid_irq+0x70/0x128 [ 11.143441] harq+0x24/0x30 [ 11.143450] gic_handle_irq+0x8c/0xa8 [ 11.143455] call_on_irq_stack+0x24/0x4c [ 11.143460] do_interrupt_handler+0x78/0xc4 [ 11.143467] el1_interrupt+0x90/0xa0 [ 11.143472] el1h_64_irq_handler+0x18/0x24 [ 11.143478] el1h_64_irq+0x74/0x78 [ 11.143483] rcu_all_qs+0x1c/0x84 [ 11.143489] __cond_resched+0x54/0x5c [ 11.143495] rockchip_dmcfreq_opp_set_rate+0x2a0/0x46c [ 11.143502] rockchip_dmcx1c8 [ 11.143513] devfreq_update_target+0x98/0xd8 [ 11.143517] update_devfreq+0x1c/0x28 [ 11.143521] rockchip_dmcfreq_system_status_notifier+0x1c4/0x200 [ 11.143527] notifier_call_chain+0x74/0x94 [ 11.143534] blocking_notifier_call_chain+0x4c/0x78 [ 11.143541] rockchip_system_status_notifier_call_chain.isra.0+0x28/0x34 [ 11.143547] rockchip_set_system_status+0x68/0xc4 [ 11.143552] rockchip_dmcfreq_probe+0xe34/0xe6c [ 11.143557] platform_probe+0x70/0xc0 [ 11.143562] really_probe+0x1cc/0x390 [ 11.143568] __driver_probe_device+0x140/0x158 [ 11.143575] driver_probe_device+0x44/0x100 11.143581] __device_attach_driver+0x110/0x124 [ 11.143588] bus_for_each_drv+0xa8/0xd4 [ 11.143593] __device_attach+0xf0/0x174 [ 11.143600] device_initial_probe+0x1c/0x28 [ 11.143606] bus_probe_device+0x38/0x9c [ 11.143612] deferred_probe_work_func+0xd8/0xec [ 11.143618] process_one_work [ 11.143631] worker_thread+0x1fc/0x254 [ 11.143636] kthread+0xc0/0xd0 [ 11.143642] ret_from_fork+0x10/0x20 [ 11.143647] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.115-vendor-rk35xx #1 [ 11.143652] Hardware name: PinusCore RK3562 () [ 11.143655] Call trace: [ 11.143656] dump_backtrace+0xe8/0x124 [ 11.143663] show_stack+0x20/0x30 [ 11.143667] dump_stack_lvl+0x6c/0x88 [ 11.143672] dump_stack+0x18/0x34 [ 11.143677] local_cpu_stop+0x4c/0x6c [ 11.143681] ipi_handler+0xe0/0x1d0 [ 11.143686] handle_percpu_devid_irq+0x70/0x128 [ 11.143692] handle_irq_desc+0x28/0x40 [ 11.143697] generic_handle_domain_irq+0x24/0x30 [ 11.143702] gix4c [ 11.143711] do_interrupt_handler+0x78/0xc4 [ 11.143717] el1_interrupt+0x90/0xa0 [ 11.143723] el1h_64_irq_handler+0x18/0x24 [ 11.143728] el1h_64_irq+0x74/0x78 [ 11.143732] arch_local_irq_enable+0xc/0x28 [ 11.143739] cpuidle_enter+0x40/0x58 [ 11.143744] do_idle+0x21c/0x240 [ 11.143749] cpu_startup_entry+0x3c/0x40 [ 11.143754] kernel_init+0x0/0x138 [ 11.143760] arch_post_acpi_subsys_init+0x0/0x28 [ 11.143768] start_kernel+0x710/0x754 [ 11.143774] __primary_switched+0xbc/0xc4 [ 11.143782] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.1.115-vendor-rk35xx #1 [ 11.143787] Hardware name: PinusCore RK3562 (DT) [ 11.143790] Call trace: [ 11.143791] dump_backtrace+0xe8/0x124 [ 11.143797] show_stack+0x20/0x30 [ 11.143802] dump_stack_lvl+0x6c/0x88 [ 11.143807] dump_stack+0x18/0x34 [ 11.143812] local_cpu_stop+0x4c/0x6c [ 11.143816] ipi_handler+0xe0/0x1d0 [ 11.143820] handle_percpu_devid_irq+0x70/0x128 [ 11.143827] handle_irq_desc+0x28/0x40 [ 11.143831] generic_handle_domain_irq+0x24/0x30 [ 11.143836] gic_handle_irq+0x8c/0xa8 [ 11.143840] call_on_irq_stack+0x24/0x4c [ 11.143845] do_interrupt_handler+0x78/0xc4 [ 11.143851] el1_interrupt+0x90/0xa0 [ 11.143856] el1h_64_irq_handler+0x18/0x24 [ 11.143862] el128 [ 11.143872] cpuidle_enter+0x40/0x58 [ 11.143877] do_idle+0x21c/0x240 [ 11.143881] cpu_startup_entry+0x3c/0x40 [ 11.143885] secondary_start_kernel+0x190/0x198 [ 11.143890] __secondary_switched+0xb0/0xb4 I am trying to port Armbian to a custom RK3562 development board. I have applied some patches in the kernel and U-Boot to support RK3562, but the system experiences a kernel crash during boot, with error logs as described above. I have already tried using the device tree file from the Toybrick RK3562 development board, but the problem persists. Can anyone please suggest where the problem might be? I am willing to provide any additional information to assist with troubleshooting. pinuscore-rk3562.dts pinuscore-rk3562.dtsi

I think that is to be expected and working as designed (assuming I understand you correctly). At least I experience the same from my regular Intel-based laptop. When it is merely screen-blanking I can get back in via a keyboard press or mouse movement. But when the system is properly suspended a press of the power key is required. Back in the day, I had a PS/2-keyboard from Siemens Nixdorf that had a power button integrated. That one was able to wake up the attached machine. It worked like a power button on the computer itself. Similar to the one you see above. The power button is the one above the numpad, next to the Siemens logo. If I am not mistaken, mine was also labeled with a power symbol while the one I found on the net is blank. Maybe somebody still makes keyboards with such a button, I don't know. I agree it would be useful. Maybe you can use wake-on lan to achieve a similar result and wake up your machine from your phone or even repurpose one of those Internet-enabled Amazon dash buttons. Heck, come to think of it, I should really go ahead and do that myself. My power button is in an inconvenient place and I still have a couple of those dash buttons that I meant to use for IoT but never did. Edit: Looks like I am mistaken and it should be possible to wake up from suspend via USB. I'd love to learn how to enable that myself.

check the logs. /var/log, ~/.Xsession-errors, etc.

Armbian is Debian or Ubuntu with focus into hardware support. https://docs.armbian.com/#what-is-armbian Many operating systems in this segment are derived or use Armbian kernel (development & support) maintained by our team and surrounding community. I do agree with your findings, but this is expected in this world. Achieving and keeping full functionality on custom hardware is hard without substantiation investments or big enough crowd of volunteers / random people that knows special stuff. Both is limited. ALSA is a complex part of engineering that I only understand to some small degree. For most people, including me - is hard to comment. I hope your findings are valuable for someone that knows where to look. Isn't always like this? Sadly, in most cases, problems are solved by investing time for research - code / structure complexity is often extreme, also for people that live source code. Welcome to Armbian forum!

ES-8388 Analog Audio Works At Fractional Volume (a possible solution) The issue of no ES-8388 analog audio output has been dragging on for months, and in all three kernel flavors (vendor, mainline, edge). I've discovered, at least with the latest edge kernel (as of Armbian 25.8.1 today), that the audio through the ES-8388 IS actually coming out, and the sound is clear. It's just that the volume that can be heard is extremely low and barely perceptible if all volume controls are maxed out and the audio file itself is at full volume range. This Bug Is From The Kernel / Driver Development Before It Gets To Armbian This is not new, I'd discovered this earlier and on other operating systems as well. So I know the issue is coming from the kernel / driver development, before it gets to Armbian. My Thought: The Audio Is Bit-Shifted by 7 or 8 bits I would venture an educated guess that the audio is 1/128 or 1/256 the correct levels (i.e. bit-shifted by 7 or 8 bits). This could be caused by, for example, a 24-bit audio integer value being copied into a 32-bit integer buffer without bit-shifting by 8 bits to align the MSBs (most significant bytes). The sign bit could be why it may be 7 instead of 8. The Easy Fix (for someone familiar w/ the source code) If this is the case, then someone familiar with the source code, who knows where this is - it would be a real simple fix. On Fedora KDE, I was able to crank up the volume even beyond max settings to try to make it louder, and it got clamped instead. My thought is that this confirms that the issue is the final mix is going to the device, which would make sense.

Sorry to bump an old thread. I am having the exact same issue here with that predefined build. I tried building moonlight-qt from source after installing ffmpeg-rockchip, I still cant get hardware decoding working... I am on a pure Wayland setup. Anyone have any tips to get this to work? What needs to be changed in the qt.pro files?

What does the following command show? sudo fdtoverlay -v -i /sys/firmware/fdt -o /dev/null /path/to/your_overlay.dtbo panel-simple-dsi ... Expected bpc in {6,8} but got: 0 So possibly the default with the older kernel was by accident correct and now you should define it. And it seems that you use an overlay meant for the 5a on a 5c?

Can you try if any of the H3 images from libre-elec would get you video acceleration? https://libreelec.tv/downloads/allwinner/ i once tried the orange pi pc image in my orange pi zero lts (h3) and it worked

hello "I need the MiniLoaderAll.bin for RK229Q-221P-V1.3 (2020.10.10). do you have it

Hi friends, back to the Gnome version which works incredibly well It works so well that I put my big desktop tower away and have been getting by strictly on this Armbian Gnome environment. I will be donating to Armbian soon However, I am curious, does anybody know how to fix the resume from suspend? For me, the computer goes into suspend mode just fine, but when I tap a keyboard key, the LED's will light on the keyboard indicating they have power, but the system never comes back. If I press the power button on the Orange Pi 5 itself, the system resumes perfectly -- no crashes, everything works as intended I just need it to work from a keyboard press instead! Thanks!

Exactly -- this is the same symptom I experience as well, plasmashell window popups with error reporting. Some retry buttons and so on, none of which do anything significant

Those specific patches only apply to the H61X SOCs. Very Strange that hardware decoding is apparently slower. Out of interest if you run something like glxgears to see what the reported screen refresh rate is. Not impossible to be the VPU but I suspect it is more likely to be the dma-buf transfers which could be a potential bottleneck. Could you provide a more detailed log by --log-file=test1.txt When working with the framebuffer, try drm-copy instead of drm.

That issue was just dealt with by disabling cruft instead. If you want to test a newer uboot with a reenabled cruft you will again need to go into building and testing, followed by a PR.

It seems that the problem has been under consideration since mid-May, so we are waiting for a bootloader update. https://github.com/armbian/build/issues/8197

@Nick A 👍

@laibsch It seems that if you set the pixel clock or refresh rate too high that you can shorten its lifespan. But when you use extreme values and the display doesn't have any protection in rare cases you can even damage it. A bigger chance is driver instability or a distorted display.

Device: Orange-Pi-5-Plus Armbian-KDE-Neon After update this morning, KDE-Neon no longer boot up successfully to Plasma Desktop. Error "plasmashell" crash handle pop-up. Able to get into tty session by "ctrl+alt+F3" but not able to boot up successfully to KDE Plasma Desktop after the update/upgrade this morning.

Maybe upstream regression. KDE is using upstream testing branch.

@Nick A could you help me get the dram settings??? My box don't have root access, on aida64, it says my box has root, but the tv info (https://play.google.com/store/apps/details?id=com.saksham.developer.tvinfo&hl=en&pli=1) says it is not rooted?

pinging maintainer @Efe Çetin

@Nick A To be honest i don't really think about debug my box, but i sure will do more research after getting all settings done.

close investigation it seems to use grub, not bootp, card written does not show any activity of green led even after 10 minutes from powerup. Do you have some of the magic twanger needed to boot a pi? Thank you, gene1934

@royk What is the risk of doing that? Can you do actual hardware damage this way or would it be a case of reflashing in the worst case?