If you run Linux, or perhaps another UNIX-like operating system, you might have noticed the occurence of spurious interrupt messages on your console during startup, and sometimes later during operation as well. Well, in case you were curious, here's the deal:
In a few words..
After the bootstrapping of an operating system is complete, the system usually runs several initialisation tasks. One thing the operating system needs to do is to load into memory all subroutines that will handle incoming interrupts. The spurious interrupt is the placeholder interrupt handler that is loaded before all the others are ready, to prevent the CPU from executing random parts of memory as if they were code. Since the spurious interrupt is loaded into all the slots of the interrupt vector, it is also the default handler for all unserviced interrupts. Driver software may sometimes cause software interrupts (traps) that are incorrect (uncaught). Such interrupts are handled by the spurious interrupt handler as well.
In detail..
Whenever a peripheral device, like a mouse for instance, needs to notify the CPU that something has happened to it, it generates an interrupt signal. The CPU will then check which device generated the interrupt signal (there are a few ways to make this check but this is not the place to explain them). Once the unique number of the device is found, the CPU will use that number as an index into a list, known as the interrupt vector or interrupt vector table. That list contains the memory addresses of the interrupt service routines.
An example: say you move your mouse. Say, for argument's sake, your mouse is device number five. The mouse will then generate an interrupt signal that the CPU picks up. The CPU will store whatever it was doing so it can pick up later. Then, it will determine the number of the device, in this case five. Then it will look up the fifth address in the interrupt vector and start executing the code at the address it found. Normally, such code would send a message to the process that draws your desktop, telling it that it should move that arrow on the screen to a new location. When the message is sent, the CPU will go about its normal business.
From this, it must be clear to you that two things need to happen during system startup for this system to work. First, the interrupt service routines need to be loaded in to memory. Second, the interrupt vector needs to be filled with the proper addresses. Less obvious, but equally necessary, the processor needs to be told where the interrupt vector resides. Now, what happens if an interrupt occurs before all this initialisation is done? Well, the CPU is likely to start executing random parts of memory. The CPU will have an incorrect location for the interrupt vector. From that location, it will count memory addresses to find an interrupt address when an interrupt occurs. Then, it will jump to the incorrect address it finds and executes the 'code' there.
The easy solution is to disable all interrupts during initialisation. Unfortunately, the preemptive multitasking capability of a computer depends on the fact that the clock is able to periodically interrupt the processor. Since some of the initialisation is done by different processes that all need a chance to run, the scheduler and the interrupt mechanism that drives it need to be fully active.
The solution is quite simple. During the early stages of system startup, before each system task is allowed to do its own initialisation, the CPU is not yet switching between tasks. The boot loader is just a very simple program that has one thread of execution. one of the first things it does is to load a simple service routine called the spurious interrupt routine into memory. This is a harmless routine that just prints a message to the console and then returns. Then, it fills all slots in the interrupt vector with the address of this routine. Finally, the system will replace most of these addresses one by one with real interrupt handlers in the later stages. The spurious interrupt handler remains the default handler for unused interrupts and traps.
Actually, most spurious interrupts are caused by software. Especially driver software. Drivers might cause a software interrupt with an incorrect number, for which no real handler is available. Since the spurious interrupt handler occupies all unfilled slots in the interrupt vector, it will handle those interrupts by default.