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

[Marc Zyngier <maz@kernel.org>]

On Mon, 06 Jul 2026 16:20:13 +0100,
John <therealgraysky@proton.me> wrote:
> 
> On Monday, July 6th, 2026 at 10:40 AM, Marc Zyngier <maz@kernel.org> wrote:
> 
> > On Mon, 06 Jul 2026 15:13:27 +0100,
> > John <therealgraysky@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.

I have no doubt about this, as this is a symptom that has been wildly
reported on the list already.

> 
> 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.

And that's the problem. Pointing to the problematic patch is perfectly
fine. Asserting a root cause for the problem without any material
evidence is not good. Only the designers of the SoC can give us that
answer, and so far they have seemingly avoided communicating on this.

> 
> 
> > 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.

Thank you for that.

> > 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.

Great. Now all we need is an explanation, and we can go back to
business as usual.

Florian?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.