From: John Ogness <john.ogness@linutronix.de>
To: Imre Kaloz <kaloz@kernel.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>,
linux-serial@vger.kernel.org, Petr Mladek <pmladek@suse.com>,
Steven Rostedt <rostedt@goodmis.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: [PATCH] MIPS: SGI-IP27: print the NMI dump on an nbcon console
Date: Thu, 01 Oct 2026 20:07:20 +0206 [thread overview]
Message-ID: <87bj9d8fm7.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <55083820-478c-e6a6-b129-467140f161db@kernel.org>
On 2026-10-01, Imre Kaloz <kaloz@kernel.org> wrote:
> nmi_dump() has no caller in Linux. install_cpu_nmi_handler() stores
> its address in the per-CPU NMI vector the PROM keeps in low memory,
> and the PROM jumps to it when the system controller asserts NMI on
> the CPUs: the "nmi" command at the L1 (or the MMSC on an Origin
> 2000), typically used to get a dump out of a hung machine.
>
> Every CPU that takes the NMI enters nmi_dump(). The first one to get
> nmi_lock waits until all online CPUs have arrived, prints the saved
> state of every CPU and ends with the NI_PORT_RESET write. The others
> spin on nmi_lock, which is never released. No CPU goes back to the
> interrupted context
Thanks for the explanation. I guess it should have been obvious, also
because @nmi_lock is locked and never unlocked.
> @@ -183,6 +184,12 @@ static void nmi_dump(void)
> */
> arch_spin_lock(&nmi_lock);
>
> + /*
> + * No CPU leaves the NMI handler before the hub reset below, so an
> + * nbcon console's printer thread would never print the dump.
> + */
> + nbcon_cpu_emergency_enter();
> +
Note that putting the CPU into emergency state does not cause any
printing. A later printk call is required.
Also note that only _this_ CPU is put into the emergency state. So any
printk's on other CPUs will not be visible until _this_ CPU performs a
printk.
In order to make sure that any backlog is flushed, I suggest also
adding:
printk_trigger_flush();
after the loop waiting for the other CPUs, just before triggering the
reset.
John
next prev parent reply other threads:[~2026-10-01 18:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 15:50 [PATCH] MIPS: SGI-IP27: print the NMI dump on an nbcon console Imre Kaloz
2026-10-01 15:56 ` sashiko-bot
2026-10-01 16:39 ` John Ogness
2026-10-01 16:52 ` Imre Kaloz
2026-10-01 18:01 ` John Ogness [this message]
2026-10-01 18:16 ` Imre Kaloz
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=87bj9d8fm7.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=kaloz@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=tsbogend@alpha.franken.de \
/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.