What is the mapping of hardware interrupts (all the IRQs and NMI) and [CPU-generated interrupts](https://fd.lod.bz/rbil/interrup/cpu/index.html) (such as division by zero) to real-mode interrupt vectors at BIOS boot time, i.e. at the time the BIOS has finished loading the boot sector from the floppy or the MBR from the hard disk, in real mode? I'd like to get a full list of these. As part of this, how has BIOS set up the PIC to map IRQs to interrupt vectors? I've compiled my list based on online sources (see below). My questions are: is the list below correct, what happens in the **CONFLICT** cases (see specific questions for each conflict), and are there any more conflicts? I'm assuming a typical IBM PC or compatible, typical BIOS, and a 8086, 186, 286, 386, 486, 586 or 686 CPU. (I hope there won't be too many CPU-specific differences.) In this question I'm not interested in protected mode or long mode, and I'm mostly not interested in how operating systems change the interrupt settings. ## Infinite loop in handling CPU-generated interrupts Upon a CPU-generated interrupt in real mode, CS:IP will point to the beginning of the offending instruction. Thus if the interrupt handler does just an *iret* (or maybe something unrelated first, and then *iret*), then the CPU will attempt to execute the same offending instruction again, calling the same interrupt handler again, thus entering an infinite interrupt handler loop. This typically happens when the BIOS has set up an interrupt handler which handles the IRQ only, ignoring the (conflicting) CPU-generated interrupt. I was able to reproduce this behavior with interrupts 05h (also BIOS print screen) and 0dh on an IBM PS/2 286 in 86Box. Here is the [boot sector code](https://gist.github.com/pts/9071b4d7f7d02cc9fb3803596cabb7a9) with which I've done the checks. This infinite loop of printing screen shots has also been a well-known behavior, for example a quote from [this answer](https://retrocomputing.stackexchange.com/a/16528): > In practice, however the `BOUND` instruction ended up getting executed unintentionally by programs that had crashed and the default BIOS handler would then get stuck in an infinite loop of printing the screen. FYi the *int N* CPU instruction doesn't cause an infinite handler loop, because this instruction pushes the address of the next instruction, so *iret* will continue from there. ## Interrupt vector list with conflicts * int 00h: CPU 8086+ divide by zero * int 01h: CPU 8086+ debugger single-step * int 02h: NMI * int 03h: CPU 8086+ breakpoint (int3) * int 04h: CPU 8086+ overflow (into) * int 05h: **CONFLICT** CPU 186+ bound range exceeded; BIOS print screen (typically this CPU interrupt causes an infinite interrupt handler loop, see above) (is it true that a smart handler can see the code being interrupted, detect the *bound* instruction easily? do most BIOSes have such a smart handler?) * int 06h: CPU 186+ invalid opcode * int 07h: CPU 286+ FPU device (coprocessor) not available * int 08h: IRQ 0: timer; (CPU 286+ double fault; can't happen in real mode) * int 09h: **CONFLICT** IRQ 1: keyboard; CPU 286,386 coprocessor segment overrun (can this happen in real mode? is it enabled by default?) * int 0ah: IRQ 2: cascade; (CPU 286+ invalid TSS; can't happen in real mode) * int 0bh: IRQ 3: COM 2/4; (CPU 286+ segment not present; can't happen in real mode) * int 0ch: IRQ 4: COM 1/3; (CPU 286+ stack-segment fault; can't happen in real mode; [RBIL](https://fd.lod.bz/rbil/interrup/cpu/0c.html) says that on 286 push with sp==1 in real mode the CPU shuts down, however on an IBM PS/2 286 in 86Box it just keeps going) * int 0dh: **CONFLICT** IRQ 5: LPT 2; CPU 286+ general protection fault, it [can happen](https://fd.lod.bz/rbil/interrup/cpu/0d.html) in real mode (typically this CPU interrupt causes an infinite interrupt handler loop, see above) (CPU interrupt confirmed on an IBM PS/2 286 in 86Box, but QEMU 2.11.1 doesn't generate it) (how is this conflict resolved by the BIOS, i.e. how smart is a typical BIOS to detect the source of the interrupt, what does a typical BIOS do?) * int 0eh: IRQ 6: floppy; (CPU 386+ page fault; can't happen in real mode) * int 0fh: IRQ 7: LPT 1; (CPU reserved) * int 10h; BIOS video services; (CPU x87 floating point exception is remapped to int 75h, see [this answer](https://retrocomputing.stackexchange.com/a/16522) and [this answer](https://stackoverflow.com/a/1634794)) * int 11h; BIOS equipment list; (CPU 486+ alignment check; can't happen in real mode) * int 12h; BIOS conventional memory size; CPU 586+ machine check (not enabled by default, set CR4.MCE to 1 to enable it; can this happen in real mode?) * int 13h; BIOS disk I/O; CPU SIMD floating point exception (not enbled by default, set CR4.OSXMMEXCPT to 1 to enable it) (can this happen in real mode?) * int 14h; BIOS serial port I/O; (CPU virtualization exception; can't happen until virtualization is set up) * int 15h; BIOS AT services, APM; (CPU control protection exception; can't happen after control protection is set up) * int 16h; BIOS keyboard I/O * int 17h; BIOS printer (parallel port) I/O * int 18h; BIOS ROM-BASIC * int 19h; BIOS reboot * int 1ah; BIOS time services, MRCI services * int 70h: IRQ 8: real-time clock * int 71h: IRQ 9: redirected IRQ2 * int 72h: IRQ 10: reserved, none by default * int 73h: IRQ 11: reserved, none by default * int 74h: IRQ 12: reserved, none by default * int 75h: IRQ 13: x87 floating point exception (remapped from CPU interrupt 10h) * int 76h: IRQ 14: hard disk (HDD) * int 77h: IRQ 15: reserved, none by default ## Links to web pages with useful info * [BIOS interrupt list](https://en.wikipedia.org/wiki/BIOS_interrupt_call) by vector. * [Intel CPU interrupt list](https://en.wikipedia.org/wiki/Interrupt_descriptor_table#Common_IDT_layouts) * [Compact IRQ list and mapping](http://www.techhelpmanual.com/96-irqs__hardware_interrupts.html) * [Compact CPU and BIOS interrupt list](http://www.techhelpmanual.com/95-interrupts_and_bios_services.html)