***AM9 Pro (S905X5) — FEL seek-panic across `Piers_nightly_20260603` (v1 + v2): all three crash sites converge on one root cause — DV metadata processing overflowing the IRQ stack (`call_on_irq_stack`).**
Module load note: `disagrees about version of symbol __stack_chk_fail — please rebuild ko` (loads + inits DV fine: `dv: s6`, `Creating DV mp success`)
Test: P7 FEL title, dual-layer confirmed (two `amvdec_h265`, 4K BL + 1080p EL, `enable_fel 1`/`enable_*mel 1`). Steady playback is flawless on every build (AMDV EL-pairing error count frozen at 1). ****The panic only occurs on skip/seek** (the DV metadata re-parse on a mode transition).
Three builds tested, three distinct crash sites — but the same bottom frame each time:
**Older build** — `Kernel stack is corrupted in: md_parser_evt_handler_cb`
`dv_md_parser_process → metadata_parser_process → amdv_parse_metadata_v2_stb`. Panicked on the *first* seek.
**`nightly_20260603` v2 (BUILD_ID `491fe10d…`)** — panicked at ~115s on a seek, and the message is explicit:
```
Kernel panic - not syncing: kernel stack overflow
pc : ext_block_payload_read+0x64/0x22bc [dovi_gen_5_15_2026]
ext_block_payload_read (frame ~0x22bc ≈ 8.9 KB)
ext_blocks_read+0x444/0x5bc
dm_data_payload_read+0x12a4/0x1550 (~4.7 KB)
rpu_decoder_process_buffer+0x1cc/0x3dc
rpu_decoder_get_output+0x128/0x174
dv_md_parser_process+0x22c/0x330
metadata_parser_process+0x128/0x31c
call_on_irq_stack+0x44/0x84
```
**Read:** every panic bottoms out at `call_on_irq_stack` — the DV metadata path is running in IRQ context on the (small, ~16 KB) IRQ stack, and these dovi functions carry very large frames (`ext_block_payload_read` ~8.9 KB, `dm_data_payload_read` ~4.7 KB). On a seek’s metadata re-parse the call depth overflows the IRQ stack. Each build just shifts the panic to whichever deep frame happens to tip it over (`md_parser_evt_handler_cb` → `Commit2DmKs/commit_reg` → `ext_block_payload_read`); v2 even reports it as a literal “kernel stack overflow.”
So this looks less like a parser logic bug and more like **the DV RPU/metadata processing needs to come off the IRQ stack** (defer to a workqueue / threaded handler) or the big on-stack buffers in `ext_block_payload_read` / `dm_data_payload_read` / `commit_reg` need to be heap-allocated. Steady playback never trips it; only the seek-time re-parse in IRQ context does.
Full console-ramoops + dmesg-ramoops for both v1 and v2 panics available on request.
according to copilot sync ensures the file is actually written to flash storage rather than just held in RAM and avoids risks with partial writes/corruption. But this is outside my areas of expertise.
Device reboots instantly when seeking during DV FEL (Profile 7) playback. No sad boot screen — just a hard restart. Playback without seeking works fine. Issue is specific to DV FEL (Profile 7) content only. Non-FEL content is unaffected.
Steps already taken:
• Fresh install of CE-NO nightly (20260605)
• Tested with 5.15_2.6_dovi_patched.ko
• Tested with 5.15_2.6_dovi_patched_fix_fel.ko (latest)
• Issue persists with both modules
• Tested on Estuary skin
Let me know if what else is needed as it is first time posting a issue
Device: Homatics Box R 4K Plus
CoreELEC build: CoreELEC-Amlogic-no.aarch64-22.0-Piers_nightly_20260606-Generic
doki file: 5.15_2.6_dovi_patched_fix_fel.ko
FEL works fine, no obvious issues found.
Bonus: I was troubleshooting a strange stutter 4k FEL playback issue for the stable NG 21.3 release, where certain 4k FEL contents trigger a short image delay intermittently while the audio keeps going. Turing Delay after change of refresh rate to 5 seconds can somehow mitigate the issue, but can’t make it go away completely. Turning off dolby vision support can address the issue, but that just misses the point of using coreelec.
I was desperate to try NO build, and it works! It not only fixes the stutter issue, but it also improves the responsiveness of the UI when I go backward and forward. I can also see the FEL information player info.
There is a stable issue here, actually, after running more tests. After playing FEL or MEL dv videos for a while, coreelect will crash and reboot automatically. I didn’t find a crash log under /storage/.kodi/temp
Same issue here with all movies, it occasionally crashes or even restarts when fast-forwarding and skipping or stoping. 1080p 25fps movies are particularly affected.
With Dolby Vision movies, occasionally there’s a synchronization issue after pausing and rebeginn, which is resolved with one or two rewinds.
