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

From: Imre Kaloz

Date: Thu Oct 01 2026 - 13:33:35 EST


Hi John,

On Thu, 1 Oct 2026, John Ogness wrote:

On 2026-10-01, Imre Kaloz <kaloz@xxxxxxxxxx> 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