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