[REGRESSION] Raspberry Pi 5 (BCM2712) hangs at boot since d87773de9efe (arm_arch_timer: default to EL2 virtual timer under VHE)

[John]

On Monday, July 6th, 2026 at 10:40 AM, Marc Zyngier <maz at kernel.org> wrote:

> On Mon, 06 Jul 2026 15:13:27 +0100,
> John <therealgraysky at proton.me> wrote:
> >
> > Since commit d87773de9efe ("clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when running VHE"), the Raspberry Pi 5 (BCM2712, arm64) hangs during boot on v7.2-rc1 and later. Reverting that commit on top of v7.2-rc2 boots reliably. Found by bisection.
> >
> > Environment: - Raspberry Pi 5 Model B, arm64, device-tree boot (no ACPI) - CPUs start at EL2 with VHE - Mainline v7.2-rc1 and v7.2-rc2
> >
> > Symptom: - Silent hang early in driver probe; no panic or oops. Boot banner shows
> >   "arch_timer: cp15 timer running at 54.00MHz (hyp-virt)". The first blocking, timer-backed wait during probe never returns because the EL2 virtual timer's interrupt is not delivered on this SoC, so clockevents are dead. The softlockup/hung-task detectors can't fire either, since they depend on the same dead timer.
> >
> 
> Is that a guess? Or do you know something we don't? Or worse, is this
> report entirely AI generated?

Hi Marc - I'm not a programmer, but I can use git. I performed the bisect, and verification steps by hand. I am convinced the bisect is correct based on the restoration of booting.

My RPi5B freezes when booting into d87773de9e and reverting it gives a clean boot.

I used Opus to analyze the result of the bisect in concert with the logs I captured from the serial console. I also used it to summarize everything into a concise bug report. I can't vouch for the accuracy of the interpretation, but I can confirm the problematic commit and restoration of function.


> Again, how do you know it isn't functional? Could it be, for example,
> that the firmware has not configured the interrupt correctly?

I cannot. In the future, when I use these tools, I will scope the ask to just factual content, rather than allowing them to speculate.

> A proposed fix has been posted at [1]. Until we hear from the
> implementer about the state of the HW, it is difficult to do anything.
> 
> 	M.
> 
> [1] https://lore.kernel.org/all/878q898ulx.wl-maz@kernel.org/

Thank you for linking that! I applied it on top of 7.2-rc2 (with d87773de9efe intact) and got a clean boot.