On an x86 platform the first level NMI (X86_INTR_CLASS_NMI+0) is most usually used to signal items such as memory parity errors, and the second level (X86_INTR_CLASS_NMI+1) is most usually used for peripherals or IO. If a memory parity or stability issue occurs, there is little that can be done programmatically with any reliability, since it's the memory itself that is having the problem. For this reason in QNX Neutrino we mark that first level NMI interrupt (X86_INTR_CLASS_NMI+0) as non-attachable since running code or doing much of anything else out of questionable memory doesn't make much sense in this context. Instead, the OS converts this interrupt into a SIGBUS exception for the process that caused it, or more accurately the process running when the interrupt is triggered.
Usually the second level NMI (X86_INTR_CLASS_NMI+1) is used to signal IO issues which might be recoverable or have a chance at some 'handling'. For this reason, it is attachable by default.
Specifically with regards to this interrupt, standard PC systems use the startup/lib/x86/callout_interrupt_nmi_bios.S file, which has a interrupt_config_nmi_bios callout that sets the INTR_CONFIG_FLAG_PREATTACH and INTR_CONFIG_FLAG_DISALLOWED flags for that vector. The latter flag means that user code is not allowed to attach to it. This is because the interrupt_id callout converts interrupt into a SIGBUS exception for the process that caused it.
There are some cases where hardware is wired such that this first level interrupt is used for CPU exceptions. If this is the case and for some reason the user would like to attach directly to the interrupt instead of handling the SIGBUS extension, then the only option is to modify the start-up code in such a way as to make the interrupt attachable.
NOTE: This entry has been validated against the SDP version listed above. Use caution when considering this advice for any other SDP version. For supported releases, please reach out to QNX Technical Support if you have any questions/concerns.
