07:30 <mmind00> detlevc: oh yes, that definitly sounds like overkill

07:31 <mmind00> though documenting that in the code might be nice ... so that the next person that stumbles over this, knows this without sinking time into investigating

08:28 <qschulz> https://www.cnx-software.com/2025/07/18/rockchip-unveils-rk3668-10-core-arm-cortex-a730-cortex-a530-soc-with-16-tops-npu-rk182x-llm-vlm-co-processor/

08:44 <qschulz> couple of years before that happens :)

08:54 <Ermine> was it this way with 3588?

08:56 <qschulz> https://www.cnx-software.com/2019/04/24/rk3588-8k-arm-cortex-a76-a55-soc-rockchip-roadmap-2020/ first mention on CNX

08:56 <Dex2x> They just need to add better support

08:58 <qschulz> https://forum.radxa.com/t/introduce-rock-5b-arm-desktop-level-sbc/8361 for Rock 5B

08:58 <qschulz> that's three years

08:58 <qschulz> and you couldn't buy it then I believe

08:59 <qschulz> I don't think the ARM CPU cores or ARM GPU are even announced yet, so that may make things a bit longer even?

09:01 <Ermine> Oh

09:02 <Ermine> Ok, back to 3588 business

09:02 <qschulz> Ermine: yeah you have time before RK36xx-based boards can be bought :)

09:12 <mmind00> but there was that pandemic in between, so maybe this time things will be faster

09:13 <qschulz> true that

12:52 <chewitt> detlevc possible cause for the green screen could be alignment

12:52 <chewitt> seems mesa wants things to be 64 aligned

14:19 <jaganteki> mriesch: Just checking, any further updates on VICAP on RK3588?

14:25 <detlevc> mmind00: I'll add a comment for that. I'll also add a missing Fixes tag on commit `fd0141d1a8a2 ("drm/bridge: synopsys: Add audio support for dw-hdmi-qp")`

15:48 <CounterPillow> jaganteki: he's on leave right now and will also be next week

18:20 <diederik> Is this a kernel or user space problem (dhcpcd is mentioned several times): https://paste.sr.ht/~diederik/ea49022c6e8d371d69a8666262729197c0e5f740#NanoPi%20R5S:%20hung%20task%20(blocked%20on%20a%20mutex%20likely%20owned%20by%20task%20dhcpcd)-L1003

18:26 <robmur01> it's a kernel problem if a userspace task's syscall has managed to get stuck *in* the kernel

18:28 <diederik> thanks :) I had a 'feeling' it was a kernel problem, but wasn't sure

18:32 <robmur01> I'd guess something's leaked triggers_list_lock, dhcpcd is stuck on that, and everything else is backed up behind it

18:39 <diederik> oh boy, that's in drivers/leds/led-triggers.c (1631cbdb8089 ("arm64: dts: rockchip: Improve LED config for NanoPi R5S") is from me ...)

18:42 <diederik> That's not an area where I expected problems, thanks :)

18:42 <robmur01> guess you've managed to "trigger" some weirdness in the driver :)

18:44 <diederik> Possibly. I've already found some oddities (in the DT), so there are several things to look into

18:45 <robmur01> The locking there looks fairly straightforward, nothing really stands out as suspect, so I'd start to fear some horrible subtle memory corruption thing...

18:50 <diederik> hmm, it may be more difficult to reproduce then I expected. Several boots into 6.12.35 and then (back to) 6.16-rc6 and that worked every time...

18:53 <diederik> ... while typing that, I rebooted again and now got an OOPS ;-P

18:56 <robmur01> somewhere LED/net related still, or randomly elsewhere?

19:01 <diederik> AFAICT (but I'm a 'bit' out of my league here) somewhere else: "Unable to handle kernel paging request" https://paste.sr.ht/~diederik/434ac1c8678001509e0fcf2d8153735ea8a19d96 (line 474)

19:06 <robmur01> oof, yeah... that looks like random memory corruption alright :(

19:09 <diederik> I guess the watchdog worked? It seems to have restarted itself ... but now both the red and the green led are solid ON ...

19:10 <diederik> ... and I couldn't SSH into it and it looks like loging in via serial is also failing ... just like the problem was previously (ie I expect the dhcpcd msg soon)

19:10 <diederik> It would REALLY suck if it was memory corruption :-(

19:11 <diederik> I thought I was getting close to deploying it as my (main) server ... and already assumed it may take a bit more time ... but memory corruption is a whole other ballpark

19:11 <diederik> ... and indeed I'm seeing the 'dhcpcd' problem again

19:15 <robmur01> I'd try running kernel memtest for a while at boot, see if it's something outside the kernel itself

19:16 <robmur01> I've had fun before where a bootloader leaves network Rx DMA enabled :)

19:17 <robmur01> after that, probably KASAN

19:18 <diederik> how can I run kernel memtest? I do have (some) experience with memtest on x86 ...

19:21 <diederik> ah, there's a memtest kernel param

19:38 <warpme> detlevc: fyi: i got another rk3576 device (nanopi-r76s) and on this device rkvdec3 h264 plays all ..... perfectly. Hmm well: diff between both hw (failing and working) is like: gmac eth vs rtl8152 pcie eth, etc. It is possible (i don't believe) that such diffs matters... I'll try to: create minimal dts (only emmc + usb eth + video decoder) for both: failing and working devices and see: is this matters (i don't believe). Lets see...

19:38 <warpme> I personally would bet on: 1)decoder factory (otp rom) fw issue; 2)dec-memory access issues like dram timing, etc.; 3)multiple concurrent dma to mem arbitration issues (or something like this). i'll back wit update soon....

19:48 <diederik> MEMTEST isn't enabled in my kernel config, so this will take a bit longer :-/ (my config is based on Debian's and there it's only enabled for x86)

20:46 <warpme> detlevc : fyi: after playing may videos i got again artefacts on h264 videos...so iirc i'm no the "same page" as you...

20:46 <warpme> may->many