From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Naman Jain <namjain@linux.microsoft.com>,
Jinjie Ruan <ruanjinjie@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
Thomas Huth <thuth@redhat.com>, Fuad Tabba <fuad.tabba@linux.dev>,
Thomas Gleixner <tglx@kernel.org>,
Pengjie Zhang <zhangpengjie2@huawei.com>,
mrigendrachaubey <mrigendra.chaubey@gmail.com>,
Saurabh Sengar <ssengar@linux.microsoft.com>
Subject: Re: [PATCH] arm64: smp: distinguish secondary CPUs that hang after reaching head.S
Date: Fri, 24 Jul 2026 10:53:27 +0530 [thread overview]
Message-ID: <a465cf1e-8466-451b-b0ab-ecc84c211756@arm.com> (raw)
In-Reply-To: <d52431ea-3166-459c-8f3d-988fdef63c32@linux.microsoft.com>
On 24/07/26 10:16 AM, Naman Jain wrote:
>
>
> On 7/23/2026 11:26 AM, Anshuman Khandual wrote:
>>
>>
>> On 23/07/26 8:19 AM, Jinjie Ruan wrote:
>>>
>>> 在 2026/7/22 19:30, Naman Jain 写道:
>>>> 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.
>
> Hello Anshuman,
> This sounds fair to me. Let me elaborate the problem, beyond the scope of this patch. In production, we occasionally see these crashes where one of the CPU fails to bring up online, with 0x0 status code. Hypervisor may be missing the telemetry, but the problem is that we don't know if the secondary CPU ever started executing the instructions or is stuck somewhere between the start of head.S and marking itself online at the end of secondary_start_kernel().
Why that information is useful ? If firmware is sure to have dispatched
given CPU then should not the early kernel boot failure be debugged via
generally available methods. Is this trying create an alternative ?
> There are couple of places, where we get those other status codes, but not everywhere. If the issue is not easily reproducible, experiments on local setups do not yield anything. That's where I am attempting to add some more information in kernel to debug these issues.
But wondering if the intent is to further classify failures including
entered ASM, but failed else where during boot for ease in debugging
why not add more into CPU_STUCK_REASON_* ?
next prev parent reply other threads:[~2026-07-24 5:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 11:30 [PATCH] arm64: smp: distinguish secondary CPUs that hang after reaching head.S Naman Jain
2026-07-23 2:49 ` Jinjie Ruan
2026-07-23 5:56 ` Anshuman Khandual
2026-07-24 4:46 ` Naman Jain
2026-07-24 5:23 ` Anshuman Khandual [this message]
2026-07-24 8:01 ` Naman Jain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a465cf1e-8466-451b-b0ab-ecc84c211756@arm.com \
--to=anshuman.khandual@arm.com \
--cc=catalin.marinas@arm.com \
--cc=fuad.tabba@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=mrigendra.chaubey@gmail.com \
--cc=namjain@linux.microsoft.com \
--cc=ruanjinjie@huawei.com \
--cc=ssengar@linux.microsoft.com \
--cc=tglx@kernel.org \
--cc=thuth@redhat.com \
--cc=will@kernel.org \
--cc=zhangpengjie2@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.