[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YnpzpkfuwzJYbPYj@alley>
Date: Tue, 10 May 2022 16:16:06 +0200
From: Petr Mladek <pmladek@...e.com>
To: "Guilherme G. Piccoli" <gpiccoli@...lia.com>
Cc: Ivan Kokshaysky <ink@...assic.park.msu.ru>,
Matt Turner <mattst88@...il.com>, rth@....gnu.org,
akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
bcm-kernel-feedback-list@...adcom.com,
linuxppc-dev@...ts.ozlabs.org, linux-alpha@...r.kernel.org,
bhe@...hat.com, kexec@...ts.infradead.org,
linux-edac@...r.kernel.org, linux-hyperv@...r.kernel.org,
linux-leds@...r.kernel.org, linux-mips@...r.kernel.org,
linux-parisc@...r.kernel.org, linux-pm@...r.kernel.org,
linux-remoteproc@...r.kernel.org, linux-s390@...r.kernel.org,
linux-tegra@...r.kernel.org, linux-um@...ts.infradead.org,
linux-xtensa@...ux-xtensa.org, netdev@...r.kernel.org,
openipmi-developer@...ts.sourceforge.net, rcu@...r.kernel.org,
sparclinux@...r.kernel.org, xen-devel@...ts.xenproject.org,
x86@...nel.org, kernel-dev@...lia.com, kernel@...ccoli.net,
halves@...onical.com, fabiomirmar@...il.com,
alejandro.j.jimenez@...cle.com, andriy.shevchenko@...ux.intel.com,
arnd@...db.de, bp@...en8.de, corbet@....net,
d.hatayama@...fujitsu.com, dave.hansen@...ux.intel.com,
dyoung@...hat.com, feng.tang@...el.com, gregkh@...uxfoundation.org,
mikelley@...rosoft.com, hidehiro.kawai.ez@...achi.com,
jgross@...e.com, john.ogness@...utronix.de, keescook@...omium.org,
luto@...nel.org, mhiramat@...nel.org, mingo@...hat.com,
paulmck@...nel.org, peterz@...radead.org, rostedt@...dmis.org,
senozhatsky@...omium.org, stern@...land.harvard.edu,
tglx@...utronix.de, vgoyal@...hat.com, vkuznets@...hat.com,
will@...nel.org
Subject: Re: [PATCH 10/30] alpha: Clean-up the panic notifier code
On Mon 2022-05-09 11:13:17, Guilherme G. Piccoli wrote:
> On 27/04/2022 19:49, Guilherme G. Piccoli wrote:
> > The alpha panic notifier has some code issues, not following
> > the conventions of other notifiers. Also, it might halt the
> > machine but still it is set to run as early as possible, which
> > doesn't seem to be a good idea.
Yeah, it is pretty strange behavior.
I looked into the history. This notifier was added into the alpha code
in 2.4.0-test2pre2. In this historic code, the default panic() code
either rebooted after a timeout or ended in a infinite loop. There
was not crasdump at that times.
The notifier allowed to change the behavior. There were 3 notifiers:
+ mips and mips64 ended with blinking in panic()
+ alpha did __halt() in this srm case
They both still do this. I guess that it is some historic behavior
that people using these architectures are used to.
Anyway, it makes sense to do this as the last notifier after
dumping other information.
Reviewed-by: Petr Mladek <pmladek@...e.com>
Best Regards,
Petr
Powered by blists - more mailing lists