What are Interrupt Requests?

SafeBytes Software

Interrupts happen when the device sends a signal to the CPU to notify it when they have data to transfer, or when an operation is complete. This allows the CPU to perform other tasks when there are no I/O transfers at that moment.

After every single instruction, the CPU has an 'interrupt request line' that is read, which ensures that during the process peak performance can be achieved by fast communication when data is to be transferred or when the operation has reached its end.

There is a common process for which interrupts and errors are handled between the CPU and devices. If a device controller has alerted an interrupt, the following will happen:1. The CPU first reads that the device driver initiates communication through the I/O.2. the I/O controller then responds by initiating the I/O for status information.3. The I/O status reads either that the input is ready, output complete, or an error has occurred, which will send out an interrupt to the CPU. 4. The CPU receives the interrupt signal and then instructs the interrupt handler to take control.5. The interrupt handler then processes the data that has been transmitted and returns from interrupt.

6. The CPU then resumes the processing of the task once the error has been fixed.

This description is for simple interrupt driven I/O. There are however three situations to where a simple interrupt driven I/O can cause problems.

1. During critical processing, there is a need to defer interrupt handling, so that the CPU can carry on with a task. 2. The CPU needs to determine which interrupt handler to raise. This is a problem because it will need to poll each device to see which one needs attention.3. The system needs to differentiate between high and low priority interrupts for a faster response, so the need for multi-level interrupts are important.

The problems listed above are ones that will hinder performance greatly, thus the interrupt-controller hardware has been created out of necessity. Most modern CPUs will have two or more interrupt request lines.

• The first line will be non-maskable. This line is strictly for critical error type conditions that will bring attention to the issue even during critical processing.

• The second line is the maskable line. Most other errors and other situations that send data to the interrupt-controller can be temporarily ignored during critical processing.

The lines work through a programmable interrupt vector which decides how to file the data to be able to determine which error to fix. The interrupt line reads an address sent from the device which is a set of numbers directly from the error table, or interrupt vector. This table is located at the physical address zero. And it holds the information used to read the addresses of routines to process errors or interrupts.

The number of interrupt handlers far outweighs the interrupt numbers, which causes the interrupt controller to handle multiple interrupts at a time. This is called chained interrupts.

DriverAssist can scan and review your computer and download the drivers you need to keep your computer devices running smoothly.