All Activity

Many thanks @c0rnelius! Is there a build available to test these patches for bluetooth? Upgrading from 25.2.2 Debian standard image or only in rolling (Trixie or Plunkie)? Denis

My pihole is a virtual machine; I do not use SD-card for it, I keep virtual machine 'objects' around on various machines, so I do not have to wait 'burning' SD-cards. I can tell way more to prevent further assumptions being made about how I operate computers in my home and foreign country, but this is getting boring. I won't click all the various URLs. I would rather start using bcachefs (again) and see how long it will take before Kent Overstreet will have added a send|receive in there like now is available in ZFS and Btrfs. But it seems you did not get the point that I use the word 'snapshot' to identify both: (pseudo code) raspi1:/.snapshots/numberX/snapshot and othermachine:/backups/numberY/snapshot (and multiple othermachines, clone NAS as I said) On raspi1 it is local on SD-card, on othermachine(s) is the exact same filetree and same subvol (received) UUID. If I would not trust btrfs send|receive, which could be the case sometimes when doing btrfs development kernel patching around 2013 timeframe, I could do a an rsync -avxc between the 2, where 1 side is a just taken RW snapshot of the otherwise RO snapshot. So you will see rsync do writes to the RW subvol if something had gone wrong with kernel implementation or userspace. Or if i manually poked 1 sector random data in some some random file at some random offset (simulating a HDD bad sector). I have done that as test several times. It take time to do that between 2 4TB HDDs but not a problem.

Look for a PR in the next few days

The bug arose with kernel commit: 21cfbeae7d7c54a6cdea4b00096150f438f4fbde ASoC: rockchip: i2s_tdm: Re-add the set_sysclk callback Committer Greg Kroah-Hartman<gregkh@linuxfoundation.org> Author Detlev Casanova<detlev.casanova@collabora.com> Author date 1/17/25 8:31 AM Parent RISC-V: Mark riscv_v_init() as __init Child io_uring/uring_cmd: use cached cmd_op in io_uring_cmd_sock() Branch kernel-rockchip64-6.12 (io_uring/uring_cmd: use cached cmd_op in io_uring_cmd_sock()) Follows test (ASoC: Intel: sof_sdw: Fix DMI match for Lenovo 83JX, 83MC...) ASoC: rockchip: i2s_tdm: Re-add the set_sysclk callback [ Upstream commit 5323186e2e8d33c073fad51e24f18e2d6dbae2da ] In commit 9e2ab4b18ebd ("ASoC: rockchip: i2s-tdm: Fix inaccurate sampling rates"), the set_sysclk callback was removed as considered unused as the mclk rate can be set in the hw_params callback. The difference between hw_params and set_sysclk is that the former is called with the audio sampling rate set in the params (e.g.: 48000 Hz) while the latter is called with a clock rate already computed with sampling_rate * mclk-fs (e.g.: 48000 * 256) For HDMI audio using the Rockchip I2S TDM driver, the mclk-fs value must be set to 128 instead of the default 256, and that value is set in the device tree at the machine driver level (like a simple-audio-card compatible node). Therefore, the i2s_tdm driver has no idea that another mclk-fs value can be configured and simply computes the mclk rate in the hw_params callback with DEFAULT_MCLK_FS * params_rate(params), which is wrong for HDMI audio. Re-add the set_sysclk callback so that the mclk rate is computed by the machine driver which has the correct mclk-fs value set in its device tree node. Fixes: 9e2ab4b18ebd ("ASoC: rockchip: i2s-tdm: Fix inaccurate sampling rates") Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Link: https://patch.msgid.link/20250117163102.65807-1-detlev.casanova@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>

That does not change anything about the FIRST send you do, it will take just as long as a dd does while rsync does it in 10% of that time. -p does the same thing as an rsync does to files that has already been rsync:d, the difference is rsync only looks at the data in the files while a send|receive also syncs the entire structure of the filesystem, that's the whole point with the COW snapshot method. So if parent is corrupted without you knowing it (witch is very often the case), so will the child. And as a rule of thumb in backups, you should have multiple backups, the 3-2-1 model is a good guidance. The downside with snapshots is they inherit the flaws of the parent, that is why it is common knowledge (or should be) that snapshots should NOT be treated as backups but ONLY as restore points. No, a scrub will not notice anything until it's too late. A scrub is just a check of the integrity of the filesystem, so if a scrub notices something is wrong the filesystem is already corrupted. So unless you also do a scrub EVERY time on the filesystem you are about to send from before sending, the receive system will also become corrupted. A complete scrub of 2TB takes a while, probably a few hours even if on an nvme. We are all different, I have all my userspace data on home, seems odd to me to rely on a network to be able to access my userspace. Would be really annoying if something were to happen to networking during for example an update or if the network interface stopped working on my desktop for some reason, maybe broken hardware in between like a switch or something. I also do a bit of AI stuff, and some models can be pretty darn big (for example some flux models are around 12GiB) so I want to be able to access them at the speed of an nvme. Other files like movies and such I keep on a network drive, I just have an NFS share on a rpi with a 4TiB spinning drive connected to it, that works just fine for me. That drive is ofc also backed up to another device with 260 incremental versions using urbackup. I'm not trying to convince you to use anything specific, I am simply trying to explain why relying soly on snapshots is not a great idea. I also think that having a restore via an img file is way easier than having only file backups in case of disaster, therefore I maintain shrink-backup. If for example my pihole dies, let's say the sd-card becomes completely unusable, I want as little downtime as possible. Writing an img file to another sd-card only takes a few minutes and the system is restored. Or even worse, if I were to utilize your system relying on a nas. If that nas dies and all my backups are on that nas, what do I do then? So as some friendly advice, I think you should reconsider your backup strategy if you want to be safe in case of complete disaster, you should always plan for worst case scenario. Here is a pretty good read on why snapshots are not considered a good strategy for backups: https://community.veeam.com/blogs-and-podcasts-57/data-backup-basics-i-why-snapshots-are-not-backups-understanding-the-differences-6074 I also rely on snapshots as restore points, but I would never rely on them alone. As an example, by using shrink-backup on my sbc:s I create an img file, I compress that img file and that file then becomes backed up with urbackup to another device (I actually exclude the img file itself in the backup), so when I update that img with shrink-backup, I rename the last compressed file with an "-old" suffix and create a new compressed file. That way I always have 2 backups accessible directly on my desktop computer. Those files are then again backed up by urbackup and are kept at least 3 months (260 backups is the actual threshold so it depends on how many backups is done per day, but minimum 3 months if my computer were to run 24/7). I also store one of those urbackup backups per month for 3 years at a location outside my house, sent encrypted via the internet to another physical location at a friends house (this could also be a cloud storage). In case of for example a fire, no matter how many backups I have at the house, they will all burn and I loose everything. A disaster only has to occur once, and by then it's too late. 3-2-1 backup strategy.

I confirm that this repository ffmpeg works for me: * Linux Edge 6.15.0 * self built image with Debian Trixie and Xfce desktop * running in X11 mode * follow all the instructions in original post Then, to make it work with an ili9488 LCD, I needed to change these: * install LCD DTS, firmware, remove plymouth * I can't make X11 work with my LCD driver panel-mipi-dbi-spi recently... (still investigating how it worked before) * but I can make it work with labwc and sway * install seatd and labwc * Choose labwc instead of xfce in lightdm login * from SSH session: DISPLAY=:0 foot& * in foot (labwc's terminal): mpv videofile.mpv

Whatever garbage ones I can find on ebay for cheap. In this case: KIOXIA 256GB SSD BG5 M.2 2230 NVMe PCIe Gen4 x4 KBG50ZNS256G https://www.ebay.com/itm/176432690192

Thanks! May I ask you what kind of NVMe drive you have installed?

I use a 12v 3a PSU "Barrel" patrick@bananapif3:~$ dmesg | grep pcie [ 0.322772] k1x-dwc-pcie ca400000.pcie: has no power on gpio. [ 0.325025] k1x-dwc-pcie ca400000.pcie: host bridge /soc/pcie@ca400000 ranges: [ 0.325065] k1x-dwc-pcie ca400000.pcie: IO 0x009f002000..0x009f101fff -> 0x009f002000 [ 0.325088] k1x-dwc-pcie ca400000.pcie: MEM 0x0090000000..0x009effffff -> 0x0090000000 [ 0.425212] k1x-dwc-pcie ca400000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4G [ 0.525297] k1x-dwc-pcie ca400000.pcie: PCIe Gen.2 x2 link up [ 0.525837] k1x-dwc-pcie ca400000.pcie: PCI host bridge to bus 0001:00 [ 0.543059] pcieport 0001:00:00.0: PME: Signaling with IRQ 65 [ 0.543510] pcieport 0001:00:00.0: AER: enabled with IRQ 65 [ 0.544202] k1x-dwc-pcie ca800000.pcie: has no power on gpio. [ 0.546446] k1x-dwc-pcie ca800000.pcie: host bridge /soc/pcie@ca800000 ranges: [ 0.546484] k1x-dwc-pcie ca800000.pcie: IO 0x00b7002000..0x00b7101fff -> 0x00b7002000 [ 0.546510] k1x-dwc-pcie ca800000.pcie: MEM 0x00a0000000..0x00afffffff -> 0x00a0000000 [ 0.546525] k1x-dwc-pcie ca800000.pcie: MEM 0x00b0000000..0x00b6ffffff -> 0x00b0000000 [ 0.646655] k1x-dwc-pcie ca800000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4G [ 1.647016] k1x-dwc-pcie ca800000.pcie: Phy link never came up [ 1.647233] k1x-dwc-pcie ca800000.pcie: PCI host bridge to bus 0002:00 [ 1.654489] pcieport 0002:00:00.0: PME: Signaling with IRQ 69 [ 1.654939] pcieport 0002:00:00.0: AER: enabled with IRQ 69 patrick@bananapif3:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mmcblk2 179:0 0 14.6G 0 disk ├─mmcblk2p1 179:1 0 508M 0 part └─mmcblk2p2 179:2 0 14.1G 0 part mmcblk2boot0 179:8 0 4M 1 disk mmcblk2boot1 179:16 0 4M 1 disk zram0 250:0 0 1.9G 0 disk [SWAP] nvme0n1 259:0 0 238.5G 0 disk ├─nvme0n1p1 259:1 0 508M 0 part /boot └─nvme0n1p2 259:2 0 238G 0 part /

Hello there, 👋 I've connected an NVMe drive that I used in my PC to the Banana Pi F3, but it's not being detected. I'm using a USB-C PD power supply (Pine64 PinePower Desktop) to ensure sufficient power, yet it's still not recognized. The drive might be faulty. Has anyone successfully used an NVMe drive with this board? If so, could you share which NVMe drives are known to work with it? Thanks! _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v25.5.1 for BananaPi BPI-F3 running Armbian Linux 6.6.87-current-spacemit Packages: Debian rolling (trixie) IPv4: (LAN) 192.168.1.185, 192.168.1.83 (WAN) 82.65.177.146 IPv6: 2a01:e0a:5ed:6230:fcfe:feff:fef8:f4be, 2a01:e0a:5ed:6230:3718:a97e:8a7b:a2c6 (WAN) 2a01:e0a:5ed:6230:9f8a:b5c1:f849:3f6f Performance: Load: 2% Up time: 1:31 Memory usage: 2% of 15.51G CPU temp: 45°C Usage of /: 12% of 113G Commands: Configuration : armbian-config Monitoring : htop [...] # Check PCIe-related kernel messages sudo dmesg | grep -E "(pcie|nvme|k1x-dwc)" # Check PCIe power management cat /sys/module/nvme_core/parameters/default_ps_max_latency_us # Monitor PCIe during boot sudo journalctl -b | grep -i pcie [ 0.404937] k1x-dwc-pcie ca400000.pcie: has no power on gpio. [ 0.407218] k1x-dwc-pcie ca400000.pcie: host bridge /soc/pcie@ca400000 ranges: [ 0.407260] k1x-dwc-pcie ca400000.pcie: IO 0x009f002000..0x009f101fff -> 0x009f002000 [ 0.407280] k1x-dwc-pcie ca400000.pcie: MEM 0x0090000000..0x009effffff -> 0x0090000000 [ 0.507413] k1x-dwc-pcie ca400000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4G [ 1.507664] k1x-dwc-pcie ca400000.pcie: Phy link never came up [ 1.508176] k1x-dwc-pcie ca400000.pcie: PCI host bridge to bus 0001:00 [ 1.514835] pcieport 0001:00:00.0: PME: Signaling with IRQ 65 [ 1.515235] pcieport 0001:00:00.0: AER: enabled with IRQ 65 [ 1.515884] k1x-dwc-pcie ca800000.pcie: has no power on gpio. [ 1.518096] k1x-dwc-pcie ca800000.pcie: host bridge /soc/pcie@ca800000 ranges: [ 1.518126] k1x-dwc-pcie ca800000.pcie: IO 0x00b7002000..0x00b7101fff -> 0x00b7002000 [ 1.518150] k1x-dwc-pcie ca800000.pcie: MEM 0x00a0000000..0x00afffffff -> 0x00a0000000 [ 1.518164] k1x-dwc-pcie ca800000.pcie: MEM 0x00b0000000..0x00b6ffffff -> 0x00b0000000 [ 1.618263] k1x-dwc-pcie ca800000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4G [ 2.618384] k1x-dwc-pcie ca800000.pcie: Phy link never came up [ 2.618513] k1x-dwc-pcie ca800000.pcie: PCI host bridge to bus 0002:00 [ 2.625055] pcieport 0002:00:00.0: PME: Signaling with IRQ 69 [ 2.625444] pcieport 0002:00:00.0: AER: enabled with IRQ 69 [ 8.000939] systemd[1]: Starting modprobe@nvme_fabrics.service - Load Kernel Module nvme_fabrics... [ 8.348576] systemd[1]: modprobe@nvme_fabrics.service: Deactivated successfully. [ 8.349624] systemd[1]: Finished modprobe@nvme_fabrics.service - Load Kernel Module nvme_fabrics. [ 9.227876] systemd[1]: nvmefc-boot-connections.service - Auto-connect to subsystems on FC-NVME devices found during boot was skipped because of an unmet condition check (ConditionPathExists=/sys/class/fc/fc_udev_device/nvme_discovery). 100000 juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca400000.pcie: has no power on gpio. juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca400000.pcie: host bridge /soc/pcie@ca400000 ranges: juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca400000.pcie: IO 0x009f002000..0x009f101fff -> 0x009f002000 juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca400000.pcie: MEM 0x0090000000..0x009effffff -> 0x0090000000 juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca400000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4G juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca400000.pcie: Phy link never came up juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca400000.pcie: PCI host bridge to bus 0001:00 juil. 04 19:00:44 bananapif3 kernel: pcieport 0001:00:00.0: PME: Signaling with IRQ 65 juil. 04 19:00:44 bananapif3 kernel: pcieport 0001:00:00.0: AER: enabled with IRQ 65 juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca800000.pcie: has no power on gpio. juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca800000.pcie: host bridge /soc/pcie@ca800000 ranges: juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca800000.pcie: IO 0x00b7002000..0x00b7101fff -> 0x00b7002000 juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca800000.pcie: MEM 0x00a0000000..0x00afffffff -> 0x00a0000000 juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca800000.pcie: MEM 0x00b0000000..0x00b6ffffff -> 0x00b0000000 juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca800000.pcie: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 4G juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca800000.pcie: Phy link never came up juil. 04 19:00:44 bananapif3 kernel: k1x-dwc-pcie ca800000.pcie: PCI host bridge to bus 0002:00 juil. 04 19:00:44 bananapif3 kernel: pcieport 0002:00:00.0: PME: Signaling with IRQ 69 juil. 04 19:00:44 bananapif3 kernel: pcieport 0002:00:00.0: AER: enabled with IRQ 69 poddingue@bananapif3 ~ $ # Enable all available kernel modules for NVMe sudo modprobe nvme sudo modprobe nvme-core sudo modprobe nvme-pci # Check if modules loaded lsmod | grep nvme modprobe: FATAL: Module nvme-pci not found in directory /lib/modules/6.6.87-current-spacemit nvme_fabrics 118784 0

Ok the backlight turning on confirms that it uses PWM0. It is worth noting at this point that PWM works but is not perfect on the A10 as the pwm-sun4i driver assumes all devices are 16-bit resolution however only the lower 8-bits are only valid on the A10. Looking into this again it would probably make it easier for yourself to include the panel parameters within the DTS as well. As mention earlier the "starry,kr070pe2t" is included within panel-simple.c. What is the current output of sudo dmesg | grep drm? I am curious to see if there is even an attempt to bind the panel. All the best Ryzer

do you have correct permissions? maybe run as root on my rock3a content is fine but got [Jul 4 20:19] warn_alloc: 19 callbacks suppressed [ +0.000026] dec0:0:hevc_rkm: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=user.slice,mems_allowed=0 [ +0.000115] CPU: 2 PID: 2339021 Comm: dec0:0:hevc_rkm Not tainted 6.1.115-vendor-rk35xx #1 [ +0.000011] Hardware name: Radxa ROCK3 Model A (DT) [ +0.000011] Call trace: [ +0.000008] dump_backtrace+0xf0/0x12c [ +0.000023] show_stack+0x20/0x30 [ +0.000011] dump_stack_lvl+0x7c/0xa0 [ +0.000016] dump_stack+0x18/0x34 [ +0.000010] warn_alloc+0xe0/0x17c [ +0.000012] __alloc_pages+0x524/0x854 [ +0.000010] __kmalloc_large_node+0xb8/0x114 [ +0.000012] __kmalloc+0x4c/0x100 [ +0.000009] __regset_get+0x60/0xd8 [ +0.000013] regset_get_alloc+0x1c/0x28 [ +0.000010] elf_core_dump+0x500/0xbc8 [ +0.000011] do_coredump+0xabc/0x100c [ +0.000012] get_signal+0x1b8/0x634 [ +0.000013] do_notify_resume+0x194/0xda8 [ +0.000010] el0_da+0x5c/0x70 [ +0.000012] el0t_64_sync_handler+0xc0/0x13c [ +0.000010] el0t_64_sync+0x19c/0x1a0 [ +0.000013] Mem-Info: [ +0.000010] active_anon:112109 inactive_anon:125820 isolated_anon:0 active_file:31285 inactive_file:45270 isolated_file:0 unevictable:0 dirty:2210 writeback:0 slab_reclaimable:16665 slab_unreclaimable:16446 mapped:15455 shmem:105 pagetables:1861 sec_pagetables:510 bounce:0 kernel_misc_reclaimable:0 free:82604 free_pcp:125 free_cma:35560 [ +0.000022] Node 0 active_anon:448436kB inactive_anon:503280kB active_file:125140kB inactive_file:181080kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:61820kB dirty:8840kB writeback:0kB shmem:420kB writeback_tmp:0kB kernel_stack:4192kB pagetables:7444kB sec_pagetables:2040kB all_unreclaimable? no [ +0.000017] DMA free:330416kB boost:14364kB min:19988kB low:21964kB high:23940kB reserved_highatomic:2048KB active_anon:448188kB inactive_anon:503568kB active_file:125312kB inactive_file:181216kB unevictable:0kB writepending:8840kB present:2095104kB managed:2014252kB mlocked:0kB bounce:0kB free_pcp:544kB local_pcp:0kB free_cma:142240kB [ +0.000018] lowmem_reserve[]: 0 0 0 0 [ +0.000015] DMA: 20626*4kB (UMEHC) 16291*8kB (UMEHC) 4462*16kB (UMHC) 1263*32kB (UMHC) 92*64kB (MHC) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 330528kB [ +0.000049] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB [ +0.000010] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=32768kB [ +0.000008] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [ +0.000009] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=64kB [ +0.000008] 129311 total pagecache pages [ +0.000007] 52636 pages in swap cache [ +0.000006] Free swap = 11240188kB [ +0.000007] Total swap = 11792380kB [ +0.000006] 523776 pages RAM [ +0.000006] 0 pages HighMem/MovableOnly [ +0.000006] 20213 pages reserved [ +0.000007] 135168 pages cma reserved command used /usr/share/jellyfin-ffmpeg/ffmpeg -y -c:v hevc_rkmpp -i 2025-06-29_22-05_rec.ts -map v -c:v h264 _rkmpp -b:v 8000k -map 0:1 -c:a copy -t 300 dvbt2.h264.ts

I have a BananaPi M1, same SoC, same kernel (the upgrade went fine for me last week). Although I only use it for its SATA connector (big HDD as NBD, OS on SD-card), audio 3.5mm plug did work. Maybe I could see what mine does, but rather with a default Debian player, like mpv, works via ssh CLI. I can generate some FLAC file, but I don't want to search for the specific song/title. Also I could do a temp exfat on a loopdev or so or just play from NFS, Btrfs or Ext4 loopdev.

Hello, I had to encode lately some video files and I discovered that video encoding hardware acceleration seems to be broken. gart@orangepi5:~$ uname -a Linux orangepi5 6.1.115-vendor-rk35xx #1 SMP Tue Jun 3 13:10:51 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux gart@orangepi5:~$ sudo dmesg | grep mpp_rkvenc [ 12.705174] mpp_rkvenc2 rkvenc-ccu: probing start [ 12.705179] mpp_rkvenc2 rkvenc-ccu: probing finish [ 13.267729] mpp_rkvenc2 fdbd0000.rkvenc-core: Adding to iommu group 10 [ 13.267963] mpp_rkvenc2 fdbd0000.rkvenc-core: probing start [ 13.268179] mpp_rkvenc2 fdbd0000.rkvenc-core: Looking up venc-supply from device tree [ 13.268187] mpp_rkvenc2 fdbd0000.rkvenc-core: Looking up venc-supply property in node /rkvenc-core@fdbd0000 failed [ 13.268207] mpp_rkvenc2 fdbd0000.rkvenc-core: rockchip_init_read_margin: no regulator (venc) found: -19 [ 13.268214] mpp_rkvenc2 fdbd0000.rkvenc-core: bin=0 [ 13.268293] mpp_rkvenc2 fdbd0000.rkvenc-core: Failed to get leakage [ 13.268342] mpp_rkvenc2 fdbd0000.rkvenc-core: Looking up venc-supply from device tree [ 13.268350] mpp_rkvenc2 fdbd0000.rkvenc-core: Looking up venc-supply property in node /rkvenc-core@fdbd0000 failed [ 13.268367] mpp_rkvenc2 fdbd0000.rkvenc-core: error -ENODEV: _opp_set_regulators: no regulator (venc) found [ 13.268395] mpp_rkvenc2 fdbd0000.rkvenc-core: failed to set opp config [ 13.268401] mpp_rkvenc2 fdbd0000.rkvenc-core: failed to init opp info [ 13.268406] mpp_rkvenc2 fdbd0000.rkvenc-core: failed to init_opp_table [ 13.268453] mpp_rkvenc2 fdbd0000.rkvenc-core: attach ccu as core 0 [ 13.268489] mpp_rkvenc2 fdbd0000.rkvenc-core: probing finish [ 13.268700] mpp_rkvenc2 fdbe0000.rkvenc-core: Adding to iommu group 11 [ 13.268940] mpp_rkvenc2 fdbe0000.rkvenc-core: probing start [ 13.269126] mpp_rkvenc2 fdbe0000.rkvenc-core: Looking up venc-supply from device tree [ 13.269135] mpp_rkvenc2 fdbe0000.rkvenc-core: Looking up venc-supply property in node /rkvenc-core@fdbe0000 failed [ 13.269152] mpp_rkvenc2 fdbe0000.rkvenc-core: rockchip_init_read_margin: no regulator (venc) found: -19 [ 13.269159] mpp_rkvenc2 fdbe0000.rkvenc-core: bin=0 [ 13.269199] mpp_rkvenc2 fdbe0000.rkvenc-core: Failed to get leakage [ 13.269231] mpp_rkvenc2 fdbe0000.rkvenc-core: Looking up venc-supply from device tree [ 13.269238] mpp_rkvenc2 fdbe0000.rkvenc-core: Looking up venc-supply property in node /rkvenc-core@fdbe0000 failed [ 13.269253] mpp_rkvenc2 fdbe0000.rkvenc-core: error -ENODEV: _opp_set_regulators: no regulator (venc) found [ 13.269272] mpp_rkvenc2 fdbe0000.rkvenc-core: failed to set opp config [ 13.269278] mpp_rkvenc2 fdbe0000.rkvenc-core: failed to init opp info [ 13.269283] mpp_rkvenc2 fdbe0000.rkvenc-core: failed to init_opp_table [ 13.269345] mpp_rkvenc2 fdbe0000.rkvenc-core: attach ccu as core 1 [ 13.269379] mpp_rkvenc2 fdbe0000.rkvenc-core: probing finish When I try to encode my files are fucked up and I have this in log : gart@orangepi5:~$ sudo cat /var/log/syslog 025-07-04T19:38:45.309928+02:00 orangepi5 mpp[3513]: mpp_serivce: mpp_service_ioc_attach_fd failed ret -1 errno 22 Invalid argument 2025-07-04T19:38:45.311485+02:00 orangepi5 kernel: rk_vcodec: mpp_process_request:1434: can not import fd 127 2025-07-04T19:38:45.311503+02:00 orangepi5 kernel: rk_vcodec: mpp_collect_msgs:1622: session 1 process cmd 401 ret -22 2025-07-04T19:38:45.311504+02:00 orangepi5 kernel: rk_vcodec: mpp_dev_ioctl:1732: collect msgs failed -22 2025-07-04T19:38:45.311505+02:00 orangepi5 kernel: rk_vcodec: mpp_task_attach_fd:1841: can't import dma-buf 271 2025-07-04T19:38:45.311506+02:00 orangepi5 kernel: rk_vcodec: mpp_translate_reg_address:1897: reg[ 0]: 0x0000010f fd 271 failed 2025-07-04T19:38:45.311507+02:00 orangepi5 kernel: rk_vcodec: mpp_task_dump_mem_region:2084: --- dump task 0 mem region --- 2025-07-04T19:38:45.311508+02:00 orangepi5 kernel: mpp_rkvenc2 fdbd0000.rkvenc-core: no memory region mapped 2025-07-04T19:38:45.311509+02:00 orangepi5 kernel: rk_vcodec: mpp_process_task_default:589: alloc_task failed. 2025-07-04T19:38:45.311510+02:00 orangepi5 kernel: rk_vcodec: mpp_process_request:1434: can not import fd 128 2025-07-04T19:38:45.311511+02:00 orangepi5 kernel: rk_vcodec: mpp_collect_msgs:1622: session 1 process cmd 401 ret -22 2025-07-04T19:38:45.311512+02:00 orangepi5 kernel: rk_vcodec: mpp_dev_ioctl:1732: collect msgs failed -22 2025-07-04T19:38:45.311513+02:00 orangepi5 kernel: rk_vcodec: mpp_task_attach_fd:1841: can't import dma-buf 273 2025-07-04T19:38:45.311515+02:00 orangepi5 kernel: rk_vcodec: mpp_translate_reg_address:1897: reg[ 0]: 0x00000111 fd 273 failed 2025-07-04T19:38:45.311516+02:00 orangepi5 kernel: rk_vcodec: mpp_task_dump_mem_region:2084: --- dump task 0 mem region --- 2025-07-04T19:38:45.311517+02:00 orangepi5 kernel: mpp_rkvenc2 fdbd0000.rkvenc-core: no memory region mapped 2025-07-04T19:38:45.311518+02:00 orangepi5 kernel: rk_vcodec: mpp_process_task_default:589: alloc_task failed. 2025-07-04T19:38:45.311520+02:00 orangepi5 kernel: rkvenc2_wait_result:2340: session 0000000017eca1cc pending list is empty! 2025-07-04T19:38:45.311520+02:00 orangepi5 kernel: rk_vcodec: mpp_msgs_wait:1693: session 1 wait result ret -5 2025-07-04T19:38:45.311521+02:00 orangepi5 kernel: rkvenc2_wait_result:2340: session 0000000017eca1cc pending list is empty! 2025-07-04T19:38:45.311523+02:00 orangepi5 kernel: rk_vcodec: mpp_msgs_wait:1693: session 1 wait result ret -5 2025-07-04T19:38:45.351471+02:00 orangepi5 kernel: rk_vcodec: mpp_process_request:1434: can not import fd 133 2025-07-04T19:38:45.351492+02:00 orangepi5 kernel: rk_vcodec: mpp_collect_msgs:1622: session 1 process cmd 401 ret -22 2025-07-04T19:38:45.351494+02:00 orangepi5 kernel: rk_vcodec: mpp_dev_ioctl:1732: collect msgs failed -22 2025-07-04T19:38:45.351495+02:00 orangepi5 kernel: rk_vcodec: mpp_task_attach_fd:1841: can't import dma-buf 274 2025-07-04T19:38:45.351495+02:00 orangepi5 kernel: rk_vcodec: mpp_translate_reg_address:1897: reg[ 0]: 0x00000112 fd 274 failed 2025-07-04T19:38:45.351497+02:00 orangepi5 kernel: rk_vcodec: mpp_task_dump_mem_region:2084: --- dump task 0 mem region --- 2025-07-04T19:38:45.351498+02:00 orangepi5 kernel: mpp_rkvenc2 fdbd0000.rkvenc-core: no memory region mapped 2025-07-04T19:38:45.351499+02:00 orangepi5 kernel: rk_vcodec: mpp_process_task_default:589: alloc_task failed. 2025-07-04T19:38:45.351500+02:00 orangepi5 kernel: rkvenc2_wait_result:2340: session 0000000017eca1cc pending list is empty! 2025-07-04T19:38:45.351501+02:00 orangepi5 kernel: rk_vcodec: mpp_msgs_wait:1693: session 1 wait result ret -5 2025-07-04T19:38:45.351502+02:00 orangepi5 kernel: rk_vcodec: mpp_process_request:1434: can not import fd 130 2025-07-04T19:38:45.351503+02:00 orangepi5 kernel: rk_vcodec: mpp_collect_msgs:1622: session 1 process cmd 401 ret -22 2025-07-04T19:38:45.351504+02:00 orangepi5 kernel: rk_vcodec: mpp_dev_ioctl:1732: collect msgs failed -22 2025-07-04T19:38:45.354822+02:00 orangepi5 kernel: rk_vcodec: mpp_task_attach_fd:1841: can't import dma-buf 270 2025-07-04T19:38:45.354845+02:00 orangepi5 kernel: rk_vcodec: mpp_translate_reg_address:1897: reg[ 0]: 0x0000010e fd 270 failed does anybody else has this behaviour ? I'm sure to have use rkmpp encoding with ffmpeg before (a long time ago) probably before kernel 6.1, and that was working. In my opinion, it's an issue with vendor kernel. Let me know. Regard

Just to confirm this is a regression issue could you also test with a clean image rather than an upgrade? It is possible something could have gone wrong during the upgrade. If I understand correctly you are only using an SD card for booting, and the kernel and main OS reside on the SSD. have you preformed an integrity check of the USB, just to ensure there is no possible file corruption? Could you also please provide the output of mocp --debug? Best of luck Ryzer

Good to meet a fellow armbian android tv box fan. We need a logo or shorthand alias for fans 🤣. ZFS - was easy but not clear. Inside armbian-config under System/Storage is a script to install ZFS support. I did this and it didn't work... then undid it and then installed it a second time and it worked. Somewhere in there I also ran the standard commands for install: sudo apt install zfsutils-linux sudo apt install zfs-fuse Probably after the first uninstall... but the commands indicate failure. But then installing the second time seemed to work. Did that on both of these boxes I have working. Thanks for the ethtool command. Here's my results on box1 ports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: Symmetric Receive-only Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: on master-slave cfg: preferred slave master-slave status: slave Port: Twisted Pair PHYAD: 0 Transceiver: external MDI-X: Unknown netlink error: Operation not permitted Current message level: 0x0000003f (63) drv probe link timer ifdown ifup Link detected: yes Not an expert and first time reading this command but looks like 1000 is the answer. Crazy thing - box 2 does not have the line "MDI-X: Unknown" shown towards the bottom and "Port: MII" instead of "Port: twisted pair" but is otherwise identical. Posting in case it helps anyone else - but these are beyond me. If you confirm that the above = 1000 I will update both my box running posts. By the way - Another favorite is Software/Management/Cockpit. Easy to see how the server is doing. Plus it has a built in terminal and file manager. Add that to Tailscale and you can check on the server or grab a file while out of the house. curl -fsSL https://tailscale.com/install.sh | sh Those are my favorites. What are yours?

The way I understand it is that you only need the full firmware package in a few exceptional circumstances. What is the wifi chipset on your SBC? Do you have the wireless-regdb package installed? "dpkg -l wireless-regdb"

Thank you for sharing. Would be good to have your findings corroborated by some of official documentation. Thanks again for sharing.

If they boot, I wouldn't worry about any difference.

I know, but who cares if it is impractical IMO and various distros by default use that path. And RPiOS needs /boot/firmware, I myself use also /boot/uboot so I am more flexible w.r.t bootloaders. What is on boot FAT or in SPI-flash or tftpboot or else is secondary, the master (from package manager) is in rootfs. Read back my 1st message; there is option -p A snapshot is identified by its UUID, whether local or remote/other/foreign filesystem. So my backup tool/script figures that out. If an SD-card would be end of life or damaged scrub will notice it and then I regenerate the whole thing on a new SD-card from the latest transferred snapshot. I do not use /home for any meaningful data. All is on NAS. Some have no local storage except SPI for bootloader. I also treat all Linux computers the same, except those that are NAS or a clone of it. For rare Windows I indeed use 'imaging' although there is WinBTRFS.

sounds good. good luck and keep us posted!

this is somewhat 'off-topic' but still relevant to 'orange pi zero 3' If Orange Pi Zero 3 is operated in warm climates (e.g. room temperature 30 deg C etc) , it can at times run up to like 60 deg C. this is in open still air adding a fan blowing at it reduce that by some 20 deg C to 40 deg C ! And this is my ghetto fan setup, no fancy case, no heatsink nothing, just a single long machine screw that lifts it up checking temperatures is easy > armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq Tcpu C.St. 18:03:39 480 MHz 0.00 0% 0% 0% 0% 0% 0% 40.8 °C 0/7^C strictly speaking, 60 deg C is 'nothing to scream about' , I've a Rpi 4 hitting up 80 deg C and it throttles. similarly use a fan blowing at it + a heat sink over the cpu, drastically reduce running temperatures. for 'occasional' use, I don't think it is necessary to have a fan blowing at the Orange Pi Zero 3. I think it is feasible to run at lower temperatures if I disable and unclock the GPU and HDMI, but for now I'm not sure how to go about doing that. Initially, I'm thinking maybe the wifi is causing it, but now I don't think so, it is moderately likely the gpu is heating it up a bit. And still air don't seem to dissipate heat very well.

Thanks for the feedback, If that was the intention. If you try the version on the testing branch, that won't be an issue because 'btrfs du' (it is just slow and unnecessary) is no longer used. xD There are actually more changes coming to btrfs in the next release. Even looking into conversion from ext4 to btrfs. Oddly enough, I can backup my arch system with boot mounted at /boot/efi using the script on main branch, wonder why yours doesn't, so clearly distro DOES matter. But it soon won't matter for the problem you had, because it will be changed anyway. Besides, shrink-backup is not really intended to be used on a desktop computer, it's for sbc:s that usually are way less convoluted than a desktop setup. For ext4 and f2fs shrink-backup only covers root and boot partitions (if boot partition exists), btrfs is an exception where the script looks up existing subvolumes and creates them. As of now, the script also assumes all subvolumes starting with @ is a top volume, witch does not actually have to be the case, but changes are coming. Interesting to see you use /boot/efi (discouraged by linux kernel standards), and not /boot as boot partition, wonder why? I do the same, because I use timeshift that is built upon snapper. Timeshift also creates entries directly on my grub menu letting me boot into the ro snapshots and restore from there if needed. For others reading this: This is because if you roll back a snapshot where you have changed things in boot process and files inside /boot, you kinda want files inside /boot to be rolled back too or your system won't boot, hence letting /boot be part of the root subvolume and mount boot partition on /boot/efi instead. My point was, that the problem you mentioned, the database might become corrupted is not solved by using snapshots and btrfs, a database has to be closed and locked to be 100% sure it won't become corrupted in ANY copy process. (beside the fact that the database in the case of pihole is only a log and has nothing to do with the integrity of the application itself) I completely disagree with that. If I revert a snapshot because I messed something up on my system or something went wrong in an update for example, witch happens once in a while, I do NOT want my home to be over-written by an old snapshot. I also want to be able to read old log-files to figure out WHAT went wrong, so /home & /var/log in separate snapshots is absolutely a good thing for me. On a sbc I might agree that separate snapshots is a bit overkill though, but not in any way a bad idea. But if you actually use snapshots as a restore points on an sbc I argue /var/log is a good thing to have on separate snapshot. A snapshot takes no time at all, 1s I would guess, but what about the send|receive? Because a snapshot is completely worthless if the filesystem you took the snapshot from becomes corrupt, COW (copy on write) means you use the exact same data. That is why it's (or should be) general knowledge that a snapshot is NOT A BACKUP, but it becomes a file-backup if you send|receive it to a completely different filesystem. So the interesting part here is the send|receive because op asked about backups, and that takes about as long as a dd would take, while rsync probably does the file transfer in about 10% of that time. Also, again, shrink-backup takes everything, including boot process parts and makes an img file at small size (for two reasons, saving space and ability to use the img file on smaller storage device, moving from a 64GiB to a 32GiB sd-card for example) that can be written directly instead of also having to do a bunch of pretty complicated restore processes. And quite a few armbian images utilizes u-boot without a boot partition with header data written to the disk before root partition, shrink-backup covers that as-well. Generally, I treat snapshots as they are intended, as snapshots that can be used as RESTORE POINTS, and I use a backup application to make regular BACKUPS. On my desktop computer I use clonezilla that I have added a menu for in grub to easily boot into (you can make custom menus and boot directly into img/iso files in grub), and on all my sbc:s I obviously use shrink-backup. (for those who don't know, I am the maintainer of shrink-backup) I also have 260 "individual" incremental file backups of my home (and some other locations like /etc and my "file disk"), one every 6h using urbackup running on a rpi4 with a 6TB disk connected to it. It utilizes btrfs so the "individual" means they are just snapshots and only changed files actually take up more space. Lastly, if you don't actually utilize the functionality of running a system with multiple subvolumes, you don't even need to have a subvolume for /, you can just write files directly to the btrfs filesystem.

apparently new images for OrangePi Zero 3 Debian minimal IOT are out on github and the boards page thanks to @Igor, @TRay, et.al. https://www.armbian.com/orange-pi-zero-3/ https://github.com/armbian/community/releases/tag/25.8.0-trunk.309 ^ apparently a big release many images ( e.g. different variants and boards) are updated, but I checked only OrangePi Zero 3 Debian minimal IOT the feature for OrangePi Zero 3 according to recent build release https://github.com/armbian/build/releases/tag/v25.8.0-trunk.293 is https://github.com/armbian/build/pull/8334 the use of u-boot tag:v2025.04 likely improves boot time ddr ram size detection.

The image from https://dl.armbian.com/orangepi5/Noble_vendor_gnome works well for me. It might be good to see some GDM logs as i am not sure where the problem arises from.