Another one which should work better: 5.15_2.6_dovi_patched_fix_fel.ko (460.8 KB)
This seems fixed the crash issue for me. The crash previously occurred when I fast-forwarded, rewound, and resumed playback. Any technical details can be shared for this one-byte patch from if x == 1 to if x >= 1?
Black magic!
3 Likes
vpeter — thank you for the updated module. I tested it on my Ugoos AM9 Pro and wanted to give you a precise report, including a kernel panic backtrace that should pinpoint the issue.
*Environment**
- Device: Ugoos AM9 Pro — S905X5 (“s6” family)
- CoreELEC: 22.0-Piers*_nightly_*20260602 (Amlogic-no)
- Kernel: 5.15.196 aarch64
- Module: `dovi_gen_5_15_2026` (your latest build) at `/flash/dovi.ko`. Loads clean: `*** amlogic_dolby_vision_init dv: s6 ***` + `Creating DV mp success`.
**Behavior — big improvement for steady playback, but it hard-panics on seek**
- *Steady* FEL playback is excellent with this build: on a Profile 7 FEL + HDR10+ title I got ~2.5 min of flawless playback — only the single startup `AMDV ERROR: bl(…) not found el` transient, zero dropped frames, smooth 24fps, both `amvdec_h265` channels decoding (BL+EL).
- **The crash is triggered by seek/skip.** As soon as I skipped during FEL playback the box hard kernel-panicked and rebooted. It reproduces on a mid-stream DV metadata transition — I caught a `Dolby VSIF, switching signal to SDR` event in the log immediately before the panic, so the seek is forcing a fresh metadata parse mid-stream.
**Kernel panic (from pstore/ramoops)**
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: md_parser_evt_handler_cb+0x1b0/0x1b0 \[dovi_gen_5_15_2026\]
Call trace:
dump_backtrace+0x108/0x154
show_stack+0x24/0x40
dump_stack_lvl+0x64/0x80
dump_stack+0x1c/0x40
panic+0x154/0x38c
metadata_parser_release+0x0/0x64 \[dovi_gen_5_15_2026\]
dv_md_parser_process+0x1fc/0x330 \[dovi_gen_5_15_2026\]
metadata_parser_process+0x128/0x31c \[dovi_gen_5_15_2026\]
parse_sei_and_meta_ext_v2+0xaf0/0xef0
parse_sei_and_meta+0x104/0x1f8
amdv_parse_metadata_v2_stb+0xa00/0x26ac
amdv_parse_metadata+0x1a4/0x1e8
amdv_update_metadata+0x98/0x158
dv_toggle_frame+0x48/0xfc
amvideo_toggle_frame+0xf18/0x243c
video_toggle_frame+0x1bc/0xa74
post_vsync_process+0x127c/0x2520
vsync_isr+0x198/0x23c
\__handle_irq_event_percpu+0xd0/0x288
handle_irq_event+0x5c/0xcc
handle_fasteoi_irq+0x118/0x218
handle_domain_irq+0x7c/0xec
gic_handle_irq+0x5c/0x11c
reboot reason = 12, kernel panic
**My read (for what it’s worth):** the stack-protector canary trips in `md_parser_evt_handler_cb`, reached via the metadata-parse path `amdv_parse_metadata_v2_stb → parse_sei_and_meta_ext_v2 → metadata_parser_process → dv_md_parser_process → metadata_parser_release`. Two things stand out: (1) the very large single-function offsets (`parse_sei_and_meta_ext_v2+0xaf0`, `amdv_parse_metadata_v2_stb+0xa00`) point to big on-stack buffers / deep frames in the SEI+RPU parser, and (2) this whole chain runs inside the **vsync ISR** (`vsync_isr → post_vsync_process → video_toggle_frame → dv_toggle_frame`), where stack headroom is tighter. So a seek that forces a fresh mid-stream metadata re-parse looks like it overruns the kernel stack in interrupt context. (Steady playback never re-parses that deeply, which is why it only crashes on seek.)
Happy to test a follow-up build, capture a 2–3s sample of the exact title, or pull any extra debug you’d find useful (full dmesg, the title’s RPU via dovi*_tool, etc.). Thanks again for the work on S905X5 FEL — steady playback is genuinely solid now; it’s just the seek path.*
1 Like
Dear, I have the AM6B+ with NO and the previous module. To use this new module, do I need to do a clean install?
No need, just replace the dovi.ko module itself.
Perfect, I installed CoreElec on the internal memory of my AM6B+, in which folder can I find the dovi.ko file?
kyrunner, instead just AI analysis the solution to the problem would be better.
1 Like
Try with the newest dovi.ko provided and with this test build:
https://test.coreelec.org/Portisch/temp/CoreELEC-Amlogic-no.aarch64-22.0-Piers_nightly_20260603.tar
And a seoncd test build:
https://test.coreelec.org/Portisch/temp/CoreELEC-Amlogic-no.aarch64-22.0-Piers_nightly_20260603_v2.tar
2 Likes
Installed V2. When skipping FEL some movies get stuck for a few seconds and then the colors are totally green. AM9 pro
what is your source? nfs/smb/other?
is it fast enough?
SMB via NAS. Never had the problem before. Around 130MB/S. Went back to the latest nightly build. Same thing.
if this is Megabytes per second (1.04Gbps) - should be fine
if this is Megabits per second (16.25MB/s) - this is too slow
Megabytes. Ok tested all 3 dovi.ko files. Same problem with transformers rise of the beasts. Its the only FEL movie to give problems (tested tens). On my AM6B+ Rise of the beast plays just fine.
I tried Transformers - Aufstieg der Bestien DV P7 FEL, too. With Portisch v1 & v2 and newest dovi.ko. I have no problem here.
Also I tried some other P7 FEL, P8.1, P5, P7 MEL. No Problems, Fast Forward, Rewind, Chapter jump Forward and Back, No Problems.
I suspect your file is simply corrupted. Some AM6B Plus Builds works also with corrupted Files.
3 Likes
Thanks for your hard work and testing. Will check your sugestion.
***AM9 Pro (S905X5) — test build `Piers_nightly_20260603` + patched dovi.ko `5.15_2.6_dovi_patched_fix_fel.ko`: big improvement on seeks, but still kernel-panics — and the crash site has moved.**
Env:
- Box: Ugoos AM9 Pro, S905X5, Amlogic-no
- Build: `CoreELEC-Amlogic-no.aarch64-22.0-Piers_nightly_20260603`
- Module: `dovi_gen_5_15_2026`, build hash `11509eb66696b72bbde0fcdbffa500e6f1764eec` (md5 of the .ko `111434c8839aa5f6ef374ef76ec0a607` — same module previously tested)
- Note at module load: `dovi_gen_5_15_2026: disagrees about version of symbol __stack_chk_fail — please rebuild ko` (loads + inits DV fine: `amlogic_dolby_vision_*init dv: s6`, `Creating DV mp success`)
What I tested (P7 FEL title, dual-layer FEL confirmed: two `amvdec*_h265` channels, 4K BL + 1080p EL, `enable_fel 1`/`enable_mel 1`):
- **Steady playback: flawless** — AMDV EL-pairing error count frozen at 1 (single startup transient), zero drops over ~15 min.
- **Seeks: survived 5+ skip/seek operations over ~12 min** before crashing. On the previous build this module kernel-panicked on the *first* seek, so the parser-side corruption looks largely addressed.
- Then at uptime ~890s it kernel-panicked during continued seeking.
**The panic backtrace moved off the metadata-parser path.** Previously (older build) it was:
`Kernel stack is corrupted in: md_parser_evt_handler_cb` (dv_md_parser_process → metadata_parser_process → amdv_parse_metadata_v2_*stb).
Now (build 20260603) it is the **DV register-commit path on the IRQ stack**:
```
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
Commit2DmKs+0xd10/0xd14 [dovi*_gen_5_15_2026]
Call trace:
panic+0x154/0x38c
Commit2DmKs+0xd10/0xd14 [dovi_gen_5_15_2026]
commit_reg+0x99c/0x2620 [dovi_gen_5_15_2026]
multi_control_path+0xdc8/0x170c [dovi_gen_5_15_2026]
amdv_control_path+0xbb4/0x13d8
call_on_irq_*stack+0x44/0x84
```
Read: looks like a stack overflow / canary smash in `commit*_reg`/`Commit2DmKs` while committing DV registers, running on the IRQ stack (`call_on_irq_stack`) — i.e. the vsync ISR path during a seek’s DV mode transition. The deep `+0x2620`/`+0x170c` offsets in `commit_reg`/`multi_control_path` suggest large on-stack buffers in that path overflowing the IRQ stack specifically.
Full console-ramoops + dmesg-ramoops available on request.***
2 Likes
Same for me , UGOOS AM6B+ 
***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`).**
Env:
- Box: Ugoos AM9 Pro, S905X5, Amlogic-no
- Module `dovi_gen_5_15_2026`, build hash `11509eb66696b72bbde0fcdbffa500e6f1764eec` (.ko md5 `111434c8839aa5f6ef374ef76ec0a607`)
- 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` v1 (BUILD_ID `968153f8…`)** — survived 5+ seeks over ~12 min, then:
```
Kernel panic: stack-protector: Kernel stack is corrupted in: Commit2DmKs+0xd10/0xd14 [dovi_gen_5_15_2026]
commit_reg+0x99c/0x2620
multi_control_path+0xdc8/0x170c
amdv_control_path+0xbb4/0x13d8
call_on_irq_stack+0x44/0x84
``` -
**`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.
1 Like