Prerequisites

What Makes the NMI Special

Every API we’ve covered so far — local_irq_disable(), disable_irq(), and friends — has one thing in common: they all work by masking ordinary maskable interrupts. The non-maskable interrupt (NMI) is architecture-specific and deliberately designed so that none of those APIs can block it. It exists so the system always has one channel of communication left even when something has gone badly wrong, such as a hung CPU core or a hardware watchdog firing.

Two important properties worth remembering: NMI lines cannot be shared between devices, and they are handled through architecture-specific code rather than the generic IRQ framework used for regular device interrupts.

Magic SysRq: A Practical Use of NMI

The kernel’s magic SysRq facility is the most common real-world use of the NMI that most developers will actually touch. On a physical keyboard it is triggered with the Alt+SysRq+<letter> key combination, but a far more scriptable and remote-friendly method is to write the letter to a special file in /proc.

# Check current sysrq setting
cat /proc/sys/kernel/sysrq

# Enable all sysrq functions temporarily (root required)
echo 1 > /proc/sys/kernel/sysrq

# List available sysrq commands in the kernel log
echo h > /proc/sysrq-trigger
dmesg | tail -20

Dumping a Backtrace on Every CPU

One of the most useful commands for a developer debugging a system that seems to be hanging is the “show backtrace on all active CPUs” function. It works by sending an NMI to every core in the system simultaneously, so it can capture exactly what each CPU is executing at that instant — even if some cores are stuck in a tight loop that would never respond to an ordinary signal.

# Trigger a kernel-mode stack backtrace on every active CPU core
echo l > /proc/sysrq-trigger

# View the captured backtraces
dmesg | tail -100

Other Frequently Used SysRq Commands

A Simple Kernel Module That Reacts to NMI-Triggered Debugging

While you cannot register your own generic NMI handler through the normal request_irq()-style APIs, you can register a kernel notifier so your driver logs helpful diagnostic state whenever a kernel panic or oops occurs — often the same moment an engineer would reach for a SysRq backtrace.

#include <linux/module.h>
#include <linux/notifier.h>
#include <linux/kdebug.h>

static int ep_diag_die_notify(struct notifier_block *nb,
                               unsigned long event, void *data)
{
    if (event == DIE_OOPS)
        pr_emerg("ep_diag: kernel oops detected, dumping driver state\n");

    return NOTIFY_DONE;
}

static struct notifier_block ep_diag_nb = {
    .notifier_call = ep_diag_die_notify,
};

static int __init ep_diag_init(void)
{
    register_die_notifier(&ep_diag_nb);
    pr_info("ep_diag: diagnostic notifier registered\n");
    return 0;
}

static void __exit ep_diag_exit(void)
{
    unregister_die_notifier(&ep_diag_nb);
}

module_init(ep_diag_init);
module_exit(ep_diag_exit);
MODULE_LICENSE("GPL");

Real-World Use Cases

• Diagnosing a soft-locked embedded board in the field by triggering an “l” SysRq command over a serial console.
• Hardware watchdogs that raise an NMI to force a diagnostic dump before a forced reboot.
• CI/lab test rigs that script SysRq commands via /proc/sysrq-trigger to capture state during automated stress tests.

Common Mistakes and Troubleshooting

Best Practices and Security Considerations

Summary / Key Takeaways

• The NMI cannot be masked by any of the enable/disable IRQ APIs, making it ideal for emergency debugging.
• Magic SysRq exposes NMI-based and other diagnostic commands through simple keypresses or /proc/sysrq-trigger.
• The “l” command dumps a backtrace from every active CPU using the NMI, which is invaluable for diagnosing hangs.
• Always restrict kernel.sysrq on production and internet-facing systems.

Conclusion

The NMI interrupt linux kernel facility, and the magic SysRq tools built on top of it, give embedded and kernel developers a last line of defense when a system seems completely unresponsive. Practicing with /proc/sysrq-trigger on a lab board today will make you far more effective the day a production system locks up. This wraps up our three-part series on interrupt handling in the free Linux kernel programming and device drivers course — check the course index for what comes next.

FAQ