next up previous contents
Next: Programmable Interrupt Controllers Up: tlk-html.html Previous: Allocating PCI I/O and

Interrupts and Interrupt Handling

  This chapter looks at how interrupts are handled by the Linux kernel. Whilst the kernel has generic mechanisms and interfaces for handling interrupts, most of the interrupt handling details are architecture specific.

   figure7525
Figure: A Logical Diagram of Interrupt Routing

Linux uses a lot of different pieces of hardware to perform many different tasks. The video device drives the monitor, the IDE device drives the disks and so on. You could drive these devices synchronously, that is you could send a request for some operation (say writing a block of memory out to disk) and then wait for the operation to complete. That method, although it would work, is very inefficient and the operating system would spend a lot of time ``busy doing nothing'' as it waited for each operation to complete. A better, more efficient, way is to make the request and then do other, more useful work and then be interrupted by the device when it has finished the request. With this scheme, there may be many outstanding requests to the devices in the system all happening at the same time.

There has to be some hardware support for the devices to interrupt whatever the CPU is doing. Most, if not all, general purpose processors such as the Alpha AXP uuse a similar method. Some of the physical pins of the CPU are wired such that changing the voltage (for example changing it from +5v to -5v) causes the CPU to stop what it is doing and to start executing special code to handle the interruption; the interrupt handling code. One of these pins might be connected to an interval timer and receive an interrupt every 1000th of a second, others may be connected to the other devices in the system, such as the SCSI controller. Systems often use an interrupt controller to group the device interrupts together before passing on the signal to a single interrupt pin on the CPU. This saves interrupt pins on the CPU and also gives flexibility when designing systems. The interrupt controller has mask and status registers which control the interrupts. Setting the bits in the mask register enables and disables interrupts and the status register returns the currently active interrupts in the system. Some of the interrupts in the system may be hardwired, for example, the real time clock's interval timer may be permanently connected to pin 3 on the interrupt controller. However, what some of the pins are connected to may be determined by what controller card is plugged into a particular ISA or PCI slot. For example, pin 4 on the interrupt controller may be connected to PCI slot number 0 which might one day have an ethernet card in it but the next have a SCSI controller in it. The bottom line is that each system has its own interrupt routing mechanisms and the operating system must be flexible enough to cope.

Most modern general purpose microprocessors handle the interrupts the same way. When a hardware interrupt occurs the CPU stops executing the instructions that it was executing and jumps to a location in memory which either contains the interrupt handling code or an instruction branching to the interrupt handling code. This code usually operates in a special mode for the CPU, interrupt modeand, normally, no other interrupts can occur in this mode. There are exceptions though; some CPUs rank the interrupts in priority and higher level interrupts may happen. This means the first level interrupt handling code must be very carefully written and it often has its own stack which it uses to store the CPU's execution state (all of the CPU's normal registers and context) before it goes off and fully handles the interrupt. Some CPUs have a special set of registers that only exist in interrupt mode and the interrupt code can use these registers to do most of the context saving it needs to do. When the interrupt has been handled, the CPU's state is restored and the interrupt is dismissed. The CPU will then continue to doing whatever it was doing before being interrupted. It is important that the interrupt processing code is as efficient as possible and that the operating system does not block interrupts too long.




next up previous contents
Next: Programmable Interrupt Controllers Up: tlk-html.html Previous: Allocating PCI I/O and

David A. Rusling
david.rusling@reo.mts.dec.com