NonStop S-Series Server Description Manual (G06.24+)

Interrupt System

HP NonStop S-Series Server Description Manual—520331-003

8-2

Interrupt Overview

Figure 8-1 is a simplified overview of the sequence by which an interrupt condition

temporarily stops the execution of the current process (or possibly some other interrupt

handler), executes the interrupt handler that is appropriate for the particular interrupt

condition, and eventually restores control to the interrupted program code.

Step 1 assumes that there is some code currently executing.

In Step 2, some interrupt condition occurs. As indicated in Figure 8-1, such interrupt

conditions are generally grouped into four categories, each processed a little

differently. Although there are other forms of interrupts than those identified in the

figure, such interrupts are handled within the RISC chip or in the millicode, and do not

require processing by an interrupt handler.

One category comprises those conditions for which the processor requires attention,

such as arithmetic overflow condition. Another category is for ServerNet attention, such

as the arrive of an incoming packet through the ServerNet hardware into an interrupt

queue. Still another category is for system software attention, such as to dispatch a

process.

Many interrupts do not get processed immediately. For others, the processor evaluates

incoming interrupts on the basis of priority and also masking (some interrupts can

prohibit processing of certain other interrupts until they themselves have been

serviced). Other interrupts of a particular kind are queued (first in, first out) before they

even get considered for processing.

Eventually, however, a given interrupt is allowed to interrupt the code of the current

program (Step 3), and the processor begins the execution of the appropriate interrupt

handler (Step 4). In the case of a page fault, an interrupt does not occur; instead, the

page fault is handled by system code in the process environment.

Finally, after the interrupt handler has run to completion, it passes control back to the

interrupted code (Step 5)—that is, assuming that the interrupted code still has highest

execution priority. Conceivably, some other code may have achieved higher priority

during the time that the interrupt handler was running, and the interrupted code must

wait its turn.