[PATCH] MIPS: SGI-IP27: print the NMI dump on an nbcon console

[PATCH] MIPS: SGI-IP27: print the NMI dump on an nbcon console

[Imre Kaloz]

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.

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.

base-commit: 5dd1818b15d98d4a20806cd00b1b40320b06004f
-- 
2.47.3

Re: [PATCH] MIPS: SGI-IP27: print the NMI dump on an nbcon console

[John Ogness]

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

Re: [PATCH] MIPS: SGI-IP27: print the NMI dump on an nbcon console

[Imre Kaloz]

Hi John,

On Thu, 1 Oct 2026, John Ogness wrote:

> 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?

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, so the printer kthread never runs, which is why
the dump never reaches the 8250 console today.

On the IP35 machines I tested the reset write takes effect and the PROM 
restarts right after the dump.

<snip>

>> @@ -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?

If the reset write did not take effect, nmi_dump() would return to
the PROM.


Best,
Imre

Re: [PATCH] MIPS: SGI-IP27: print the NMI dump on an nbcon console

[John Ogness]

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

Re: [PATCH] MIPS: SGI-IP27: print the NMI dump on an nbcon console

[Imre Kaloz]

Hi John,

On Thu, 1 Oct 2026, John Ogness wrote:

> 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.
>

Makes sense, thanks. v2 will flush after the dump, right before the 
NI_PORT_RESET write.


Best,
Imre