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

[Stefan Wahren]

[Add Raspberry Pi maintenance]

Am 10.07.26 um 10:14 schrieb 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/