RPi5B hardlock when kodi plays begins playing a file

[graysky2]

Describe the bug

Since updating the kernel built on the rpi-6.18.y branch, asking kodi to play a file will hardlock the RPi5B. Perplexingly, there nothing written to journalctl nor to kodi.log. The screen just hangs, the board looses network connectivity and can only be recovered by a hard reset.

Last known good kernel commit: e2361ee
First known bad kernel commit: 8d00685

I have verified the reproducibility of this and it is solid. Downgrading the kernel with no other changes fixes the bug. Install the kernel built from 8d006854d triggers the bug everytime.

Steps to reproduce the behaviour

Bug manifests on Arch ARM. Begin with an up-to-date image. Install kodi-rpi-git. The bug can be triggered by playing a HEVC video such as jellyfish from the kodi free video wiki page.

Device (s)

Raspberry Pi 5

System

• ArchARM does not have this file
• 2025/12/08 19:29:54 Copyright (c) 2012 Broadcom version 2226a853 (release) (embedded)
• Linux submyth 6.18.16-1-rpi-16k #1 SMP PREEMPT Fri Mar 6 13:30:28 UTC 2026 aarch64 GNU/Linux

Logs

As stated, nothing is written to journalctl nor kodi.log, just a hard lock.

Additional context

Are there any smoking gun commits or am I stuck bisecting?

e2361ee...8d00685

[popcornmix]

Does latest 6.18 kernel with #7256 reverted fix it?
As they cause v3d clock to be disabled it seems plausible it could cause a lock up if something goes wrong.

[graysky2]

@popcornmix - I believe that is 8d00685 which is HEAD for the 6.18 branch and it does not fix it.

[HiassofT]

6.18.16 without the changes from #7256 (commit e7fec0d) works fine here in LE, current HEAD (8d00685) also locks up hard.

[graysky2]

I bisected it to: 44d0986

44d09862b50a31d44521ab50600e4bba0da56d56 is the first bad commit
commit 44d09862b50a31d44521ab50600e4bba0da56d56
Author: Maíra Canal <mcanal@igalia.com>
Date:   Fri Jan 16 11:29:38 2026 -0300

    clk: bcm: rpi: Mark PIXEL_CLK and HEVC_CLK as CLK_IGNORE_UNUSED
    
    If PIXEL_CLK or HEVC_CLK is disabled during boot, the firmware will skip
    HSM initialization, which would result in a bus lockup. However, those
    clocks are consumed by drivers (vc4 and HEVC decoder drivers,
    respectively), which means that they can be enabled/disabled by the
    drivers.
    
    Mark those clocks as CLK_IGNORE_UNUSED to allow them to be disabled by
    drivers when appropriate.
    
    Acked-by: Melissa Wen <mwen@igalia.com>
    Signed-off-by: Maíra Canal <mcanal@igalia.com>

 drivers/clk/bcm/clk-raspberrypi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

And can confirm that indeed, that commit causes the bug whereas 570585a is good.

% git bisect log
git bisect start
# status: waiting for both good and bad commits
# good: [e7fec0d315c178d6486d9c8c79d1d393df2df338] configs: enable CONFIG_HID_CP2112=m
git bisect good e7fec0d315c178d6486d9c8c79d1d393df2df338
# status: waiting for bad commit, 1 good commit known
# bad: [8d006854d517c0892dedb73d44d9608e4dfe3e9f] [BACKPORTED] drm/v3d: Introduce Runtime Power Management
git bisect bad 8d006854d517c0892dedb73d44d9608e4dfe3e9f
# bad: [44d09862b50a31d44521ab50600e4bba0da56d56] clk: bcm: rpi: Mark PIXEL_CLK and HEVC_CLK as CLK_IGNORE_UNUSED
git bisect bad 44d09862b50a31d44521ab50600e4bba0da56d56
# good: [f9709452f1fba55fb0a3b519ad0dc4f4f44e7ec4] [DOWNSTREAM] drm/v3d: Delete downstream CLK management
git bisect good f9709452f1fba55fb0a3b519ad0dc4f4f44e7ec4
# good: [570585aff0b29caaba82466918e12b7f69e4276b] clk: bcm: rpi: Manage clock rate in prepare/unprepare callbacks
git bisect good 570585aff0b29caaba82466918e12b7f69e4276b
# first bad commit: [44d09862b50a31d44521ab50600e4bba0da56d56] clk: bcm: rpi: Mark PIXEL_CLK and HEVC_CLK as CLK_IGNORE_UNUSED

[popcornmix]

@mairacanal I can reproduce this. Reverting 44d0986 does avoid the lockup when playing hevc.

I can investigate more next week, but I would have thought the hevc driver should enable the clock when needed (but there may be a bug in that driver).
Note: firmware does not touch hevc hardware, so shouldn't be involved.

[mairacanal]

@popcornmix, I've spent some time investigating this issue today and I'd say that there are only two options: (1) it is a HEVC driver bug or (2) disabling the HEVC clock could cause a bus lockup due to the structure of RPi's clock tree.

About (2), I believe you might have a better insight than me, as I don't know exactly how the clocks are related. About (1), I initially suspected an IRQ management issue (the IRQ is level-triggered, and the ICTRL state wasn't being properly reinitialized across clock cycles). The branch at [1] addresses that, but it doesn't fix the underlying hang. With this branch, most of the times I can reproduce the whole video at least once (and sometimes twice), but I still get a lockup when the clock restarts.

The key finding is that HEVC core registers (base_h265) become inaccessible after clk_disable_unprepare/clk_prepare_enable cycle, while the interrupt controller registers (base_irq) remain accessible throughout.

Do you have any insight about the bus that could justify such behavior? One thing that caught my attention is that the HEVC node has no power-domains or resets properties. Do you have any insight into what powers the HEVC core's bus interface? For example, RPi 4 has that rpivid_asb in bcm2835-pm.c, but I couldn't find something similar in RPi 5.

[1] https://github.com/mairacanal/linux-rpi/tree/hevc/fix-sys-lockup

[popcornmix]

Accessing any register in hardware clocked off the hevc clock (e.g. 0x1000800000-0x1000803ffff)(*) will lock up if the hevc clock is not running. I suspect that is the most likely cause of this issue.

@jc-kynesim any thoughts on hevc driver patches. It sounds like hevc registers are being accessed after hevc_d_hw_stop_clock (which is a bad thing).

(*) I think this is the only block clocked off the hevc clock. There are a couple of other blocks somewhat related to hevc (the interrupt controller you mentioned, and one related to setting AXI settings like priority) but I'd expect those to be clocked off main AXI bus clock.

Neither pi4 or pi5 has real power control over hevc (i.e. you can't switch off the voltage to hevc block).
Pi4 does have a clock gate ("Async Bridge Control") for v3d, isp and hevc (but I'm not sure if it gains anything in a world where clock is disabled anyway). I don't think Pi5 has an equivalent to ASB control.

[jc-kynesim]

I thought that everything was shutdown by the time I hit clock off. it was certainly the intention. Which tree should I build to reproduce this?

[popcornmix]

Current tot rpi-6.18.y shows the issue (but I'll push a revert to work around the issue soon).

[jc-kynesim]

Should this fail every time? The kernel I've just built (6-18.y) 8d00685 doesn't seem to lock up with a simple ffmpeg decode to null or vout_drm playing jellyfish

[graysky2]

In my test cases it did not trigger every time. As I was bisecting I found the bug could take multiple times to trigger, if memory serves me correctly in some cases 8 or 9 tries. My rule was if the bug did not trigger after 15 consecutive times I would call it the commit in the bisect good.

EDIT: I also did my testing in kodi, not ffmpeg. You can find your patch I used as well as the relevant kodi commit at the time here: https://github.com/graysky2/xbmc/tree/version

[jc-kynesim]

@popcornmix I'm just trying this on a clean PiOS with the kernel replaced. And it seems reliable under kodi playing jellyfish-25 and the football clip for me. Is this unexpected?

[popcornmix]

@jc-kynesim
just tried with clean 6.18.16 kernel and hevc locks up with kodi for me on Pi5.
Seems to happen every time (on several attempts).
Also occurs on a number of files (including jellyfish-90 and football).

edit: do you have any custom config/cmdline settings? e.g. forcing clocks?

[jc-kynesim]

Ah! force_turbo=1. I forgot that would work round this. Remove it and I do get the lockup