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

[Marc Zyngier]

On Mon, 06 Jul 2026 16:20:13 +0100,
John <therealgraysky@xxxxxxxxx> wrote:
> 
> On Monday, July 6th, 2026 at 10:40 AM, Marc Zyngier <maz@xxxxxxxxxx> wrote:
> 
> > On Mon, 06 Jul 2026 15:13:27 +0100,
> > John <therealgraysky@xxxxxxxxx> 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@xxxxxxxxxx/
> 
> Thank you for linking that! I applied it on top of 7.2-rc2 (with d87773de9efe intact) and got a clean boot.

FWIW, and in the absence of any feedback from the SoC manufacturer,
I've posted this patch[2]. There isn't much else I can do for this
stuff.

	M.

[2] https://lore.kernel.org/all/20260710080958.491620-1-maz@xxxxxxxxxx/

-- 
Jazz isn't dead. It just smells funny.