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

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

[John]

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.

Cause: - BCM2712's timer node lists five interrupts including the EL2 virtual
  timer (GIC PPI 12). The new default trusts that entry and switches to the EL2 virtual timer, whose interrupt is non-functional on this board.  Before the commit, VHE systems used the EL2 physical timer, which works.

Possible fix / workaround: - Removing the EL2 virtual-timer interrupt (GIC PPI 12) from the BCM2712
  timer node makes the driver fall back to the EL2 physical timer (the pre-commit behavior) and boots. Whether the correct fix is in the DT or in hardening the driver's PPI selection, I'll leave to you.

#regzbot introduced: d87773de9efe1df6fe2ba379926f9df92f1a5913

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

> Cause: - BCM2712's timer node lists five interrupts including the EL2 virtual
>   timer (GIC PPI 12). The new default trusts that entry and switches to the EL2 virtual timer, whose interrupt is non-functional on this board.  Before the commit, VHE systems used the EL2 physical timer, which works.
>

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

> Possible fix / workaround: - Removing the EL2 virtual-timer interrupt (GIC PPI 12) from the BCM2712
>   timer node makes the driver fall back to the EL2 physical timer (the pre-commit behavior) and boots. Whether the correct fix is in the DT or in hardening the driver's PPI selection, I'll leave to you.
> 
> #regzbot introduced: d87773de9efe1df6fe2ba379926f9df92f1a5913

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/

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

Re: [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@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.

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.

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