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

[Imre Kaloz <kaloz@kernel.org>]

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