mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: John Ogness <john.ogness@linutronix.de>
To: Imre Kaloz <kaloz@kernel.org>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: 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 18:45:43 +0206	[thread overview]
Message-ID: <87ece98je8.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <20261001155013.1694-1-kaloz@kernel.org>

On 2026-10-01, Imre Kaloz <kaloz@kernel.org> wrote:
> Since the 8250 console became nbcon, printk() in nmi_dump() only queues
> records for the printer thread, which never runs because no CPU leaves
> the NMI handler before the hub reset. Print the dump from an emergency
> section.

Please excuse my ignorance, but could you inform me about the context?
When is nmi_dump() called? Does the hardware always reset/reboot/hang
from this call?

> Fixes: d3539347022a ("serial: 8250: Switch to nbcon console, take 2")
> Signed-off-by: Imre Kaloz <kaloz@kernel.org>
> ---
>  arch/mips/sgi-ip27/ip27-nmi.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/arch/mips/sgi-ip27/ip27-nmi.c b/arch/mips/sgi-ip27/ip27-nmi.c
> index fc2816398d0c..4447c0bec8b4 100644
> --- a/arch/mips/sgi-ip27/ip27-nmi.c
> +++ b/arch/mips/sgi-ip27/ip27-nmi.c
> @@ -1,4 +1,5 @@
>  // SPDX-License-Identifier: GPL-2.0
> +#include <linux/console.h>
>  #include <linux/kernel.h>
>  #include <linux/mmzone.h>
>  #include <linux/nodemask.h>
> @@ -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();
> +
>  #ifdef REAL_NMI_SIGNAL
>  	/*
>  	 * Wait up to 15 seconds for the other cpus to respond to the NMI.

The CPU enters an emergency state, but shouldn't it exit the emergency
state at some point? Or does the machine always unstoppably
reset/reboot/hang after this point?

John Ogness

  reply	other threads:[~2026-10-01 16:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-01 15:50 Imre Kaloz
2026-10-01 16:39 ` John Ogness [this message]
2026-10-01 16:52   ` Imre Kaloz
2026-10-01 18:01     ` John Ogness
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=87ece98je8.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®