Messages in this thread | | | Date | Thu, 5 Jan 2023 11:40:30 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH x86/nmi 2/2] x86/nmi: Print reasons why backtrace NMIs are ignored |
| |
* Paul E. McKenney <paulmck@kernel.org> wrote:
> +#ifdef CONFIG_NMI_CHECK_CPU > + > +static char *nmi_check_stall_msg[] = { > +/* */ > +/* +--------- nsp->idt_seq_snap & 0x1: CPU is in NMI handler. */ > +/* | +------ cpu_is_offline(cpu) */ > +/* | | +--- nsp->idt_calls_snap != atomic_long_read(&nsp->idt_calls): */ > +/* | | | NMI handler has been invoked. */ > +/* | | | */ > +/* V V V */ > +/* 0 0 0 */ "NMIs are not reaching exc_nmi handler", > +/* 0 0 1 */ "exc_nmi handler is ignoring NMIs", > +/* 0 1 0 */ "CPU is offline and NMIs are not reaching exc_nmi handler", > +/* 0 1 1 */ "CPU is offline and exc_nmi handler is legitimately ignoring NMIs", > +/* 1 0 0 */ "CPU is in exc_nmi handler and no further NMIs are reaching handler", > +/* 1 0 1 */ "CPU is in exc_nmi handler which is legitimately ignoring NMIs", > +/* 1 1 0 */ "CPU is offline in exc_nmi handler and no further NMIs are reaching exc_nmi handler", > +/* 1 1 1 */ "CPU is offline in exc_nmi handler which is legitimately ignoring NMIs",
That kind of disambiguation of why a CPU is stuck looks really useful:
Reviewed-by: Ingo Molnar <mingo@kernel.org>
One small suggestion would be to do this in the messages:
s/exc_nmi handler /exc_nmi() handler
... to make it clear that it's a regular kernel function [well, hw entry handler], not a function pointer or some other indirection? No strong feelings though.
Thanks,
Ingo
| |