Question

Outline the process that occurs when a hardware interrupt is generated by a disk controller. Set the context for the interrupt disk read and describe how an interrupt handler would address the event.

Answer 1

As the name suggests,these interrrupts are set by hardware components or peripheral devices like hard disks.

Disk controller using the bus to signal that a disk request has been fulfilled.What actually happens is that disk Raises an interrupt.The disk interrupt handler then copies the retrieved data into memory for the later use by the program that made the request.When an event occurs the micro-controller generates a hardware interrupt. The interrupt forces the micro-controller's program counter to jump to a specific address in program memory. This special memory address is called the interrupt vector. At this memory location we install a special function known as an interrupt service routine (ISR) which is also known as an interrupt handler. So upon generating a hardware interrupt, program execution jumps to the interrupt handler and executes the code in that handler.

we describe interrupt handling in a scenario where the hardware does support identifying the device that initiated the interrupt. In such cases, the exact source of the interrupt can be identified at hardware level.

1. A device asserts the interrupt signal at a hardwired interrupt level.
2. The processor registers the interrupt and waits to finish the current instruction execution.
3. Once the current instruction execution is completed, the processor initiates the interrupt handling by saving the current register contents on the stack.
4. The processor then switches to supervisor mode and initiates an interrupt acknowledge cycle.
5. The interrupting device responds to the interrupt acknowledge cycle with the vector number for the interrupt.
6. Processor uses the vector number obtained above and fetches the vector.
7. The address found at the vector is the address of the interrupt service routine (ISR) for the interrupting device.
8. After the ISR routine has performed its job, the ISR executes the "return from interrupt" instruction.
9. Execution of the "return from interrupt" instruction results in restoring the processor state. The processor is restored back to user mode.

10. we describe interrupt handling in a scenario where the hardware does not support identifying the device that initiated the interrupt. In such cases, the possible interrupting devices need to be polled in software.

11. A device asserts the interrupt signal at a hardwired interrupt level.
12. The processor registers the interrupt and waits to finish the current instruction execution.
13. Once the current instruction execution is completed, the processor initiates the interrupt handling by saving the current register contents on the stack.
14. The processor then switches to supervisor mode and initiates an interrupt acknowledge cycle.
15. No device responds to the interrupt acknowledge cycle, so the processor fetches the vector corresponding to the interrupt level.
16. The address found at the vector is the address of the interrupt service routine (ISR).
17. The ISR polls all the devices to find the device that caused the interrupt. This is accomplished by checking the interrupt status registers on the devices that could have triggered the interrupt.
18. Once the device is located, control is transferred to the handler specific to the interrupting device.
19. After the device specific ISR routine has performed its job, the ISR executes the "return from interrupt" instruction.
20. Execution of the "return from interrupt" instruction results in restoring the processor state. The processor is restored back to user mode
21. While the disk is reading or writing data, the CPU can go execute instructions.

22. lMore complex than exceptions

    lRequires registry, deferred processing, etc.

    lThree types of actions:

    lCritical: Top-half (interrupts disabled – briefly!)

    lExample: acknowledge interrupt

    lNon-critical: Top-half (interrupts enabled)

    lExample: read key scan code, add to buffer

    lNon-critical deferrable: Do it “later” (interrupts enabled)

    lExample: copy keyboard buffer to terminal handler process

    lSoftirqs, tasklets.