Thread (8 messages) read the whole thread 8 messages, 4 authors, 3d ago

Re: [PATCH] arm64: smp: distinguish secondary CPUs that hang after reaching head.S

From: Anshuman Khandual <hidden>
Date: 2026-07-23 05:56:52
Also in: lkml


On 23/07/26 8:19 AM, Jinjie Ruan wrote:
在 2026/7/22 19:30, Naman Jain 写道:
quoted
When a secondary CPU fails to come online, __cpu_up() falls back to
__early_cpu_boot_status, but boot status 0x0 is ambiguous: it cannot
distinguish a CPU that never executed head.S (firmware/hypervisor never
dispatched it, so it never ran a single instruction) from one that
entered head.S, started executing, and then got stuck somewhere in kernel
bring-up. Add a change to let us tell those two cases apart, which
narrows down where to look when a CPU goes missing during boot.
I previously encountered this issue when debugging the parallel startup
of ARM64 secondary cores. It is difficult for the kernel to determine
whether the secondary core is hung in the firmware or whether it has not
executed a single instruction. So I think this motive is reasonable.
Why should kernel determine the difference here ? Would not the firmware
know if it has started any secondary CPU for the kernel which must have
come inside head.S ? If the cpu gets hung inside firmware while starting
up then the debug responsibilities belong there instead.

Still wondering what's the rationale for this change.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help