[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260108074915.GE272712@noisy.programming.kicks-ass.net>
Date: Thu, 8 Jan 2026 08:49:15 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Baoquan He <bhe@...hat.com>
Cc: Pnina Feder <pnina.feder@...ileye.com>, akpm@...ux-foundation.org,
pmladek@...e.com, linux-kernel@...r.kernel.org, lkp@...el.com,
mgorman@...e.de, mingo@...hat.com, rostedt@...dmis.org,
senozhatsky@...omium.org, tglx@...utronix.de, vkondra@...ileye.com
Subject: Re: [PATCH v4] panic: add panic_force_cpu= parameter to redirect
panic to a specific CPU
On Thu, Jan 08, 2026 at 11:11:50AM +0800, Baoquan He wrote:
> On 01/07/26 at 11:56pm, Pnina Feder wrote:
> > Some platforms require panic handling to execute on a specific CPU for
> > crash dump to work reliably. This can be due to firmware limitations,
>
> Thanks for fixing this. Could you kindly reveal which platform this
> issue is from?
>
> > interrupt routing constraints, or platform-specific requirements where
> > only a single CPU is able to safely enter the crash kernel.
> >
> > Add the panic_force_cpu= kernel command-line parameter to redirect panic
> > execution to a designated CPU. When the parameter is provided, the CPU
> > that initially triggers panic forwards the panic context to the target
> > CPU via IPI, which then proceeds with the normal panic and kexec flow.
> >
> > If the specified CPU is invalid, offline, or a panic is already in
> > progress on another CPU, the redirection is skipped and panic continues
> > on the current CPU.
>
> What if both the original CPU and specified CPU are not able to function
> well on panic jumping? The crash dumping will fail in this case?
Yes.
Powered by blists - more mailing lists