I Can't Get Interrupts Working

This page is a sort of TroubleShooting manual to help you getting through common interrupts framework problems encountered by guests and members of the forum

Make sure you collected enough information about your own situation (for instance running your code in Bochs).

ISR problems

My handler doesn't get called?! (Assembly)

For this test, you need to call the interrupt yourself, by software. Don't try to get IRQ handled right from the start before you're sure your IDT setup is correct. You need to have:

• Your IDT loaded and filled properly.
• Your IDT's linear address loaded in a structure together with the table's size (in bytes, IIRC). Be especially cautious if you have a Higher Half Kernel design or did not set up identity paging.
• A valid Code selector and offset in the descriptor, proper type, etc.
• A handling code at the defined offset.

see test code below

My Handler doesn't get called (C)?!

If you are programming the IDT setup in C, make sure the IDTR structure has been correctly understood by your compiler. As Intel's 6 bytes structures infringe most compiler's packing rules, you'll need to use either bitfields or packing pragmas. Use sizeof() and OFFSETOF() macros to make sure the expected definition is used (a runtime test would be fine)

My handler is called but it doesn't return !?

Try to run it in the Bochs and see if you get any exception report. Program all your exception to have the same kind of behavior as the example, but displaying a character indicating the fault. Exceptions occurring at the end of an interrupt handler are usually due to a wrong stack operation within the handler.

• don't try to return from an exception (unless you solved its cause). Returning from a division by zero, for instance, makes no sense at all
• pops everything you push, but no more
• make sure you didn't forget the CPU-pushed error code (for exceptions 8,10 and 14 at least)
• make sure your handler doesn't trash unexpected registers. For exceptions and hardware IRQ handlers, no registers *at all* should be modified.

Another common source of error at this point comes from mis implementation of ISR in C. Check the InterruptServiceRoutines page for enlightenment ...

IRQ problems

Now that you're sure an interrupt can be called and can return, you're ready to enable hardware interrupts. As a first step, you're suggested to enable the _keyboard handler only_, as you'll have almost complete control of what it does. Use the mask feature of the PIC to enable/disable some handlers.

   outb(0x21,0xfd);
   outb(0xa1,0xff);
   enable(); // asm("sti");

I'm receiving a General Protection Fault interrupt immediately after returning from my first interrupt

After initializing the gdt with the lgdt command, make sure that you are performing a long jump. For example:

init_gdt:
    lgdt [gdt_table]
    jmp 0x08:longjmp_after_gdt
longjmp_after_gdt:
    ; Do something like repoint segment registers next

I'm receiving EXC9 instead of IRQ1 when striking a key?!

You missed the PIC vector reprogramming step. Check Can I remap the PIC? page. Note that if you remap the PIC vectors out of the IDT you'll get a GPF exception instead of any interrupt.

I'm receiving a double fault after enabling interrupts

May be a different symptom for the same error as above, this time caused by a timer interrupt calling vector 8. May also be caused if you've enabled interrupts in protected mode but haven't got an interrupt handler defined for whatever vector you've remapped the timer to, as the timer interrupt will come soon after enabling interrupts and cause a fault unless you've got a handler for it or you've masked it.

I'm not receiving any IRQ

Make sure you receive software interrupts first. Also make sure you enabled the IRQ of your interest on the PIC mask and that you enabled the cascading line (bit #2 of the master) if you're waiting for a slave IRQ.

I can only receive one IRQ

Each IRQ needs to be acknowledged to the PIC manually by sending an EOI. You need to have

 outb(0x20,0x20)

within any master handler and any

 outb(0x20,0x20); outb(0xa0,0x20);

within any slave handler.

When handling the keyboard IRQ, make sure that you read the byte the keyboard sends you. The interrupt might not trigger again until it has been read:

 unsigned char scan_code = inb(0x60);

Also, if you are following the barebones tutorial, be sure that your main function doesn't exit too soon (because when it does, it disables interrupts). A common solution to make sure it doesn't exit prematurely is to add

 for(;;) {
    asm("hlt");
 }

to the end of your main kernel function. The for loop is necessary because execution continues after the CPU receives an interrupt.

When I try to enable the PIT, the keyboard doesn't work anymore

A common mistake is that people reload the mask with 0xFE when they want to add timer, but doing this actually enables only the timer and disables the keyboard (bit #1 of 0xFE is set!) The correct value for enabling both keyboard and timer is 0xFC.

I keep getting an IRQ7 for no apparent reason

This is a known problem that cannot be prevented from happening, although there is a workaround. When any IRQ7 is received, simply read the In-Service Register

 outb(0x20, 0x0B); unsigned char irr = inb(0x20);

and check if bit 7

irr & 0x80

is set. If it isn't, then return from the interrupt without sending an EOI.

For more information, including a more detailed explanation, see Brendan's post in this thread.

what does "shift operator may only be applied to scalar values" mean?

You're trying to load a 16-bits field (a part of the IDT descriptor) with a reference to a 32-bit label that is subject to relocation. Try to replace

 isr_label:
    iret
 bad_stuff dw isr_label & 0xFFFF
           dw 0xdead
           dw 0xbeef
           dw isr_label >> 16

by something that extracts a 'pure value' from the address (e.g. the difference of two addresses are a pure value and $$ means to NASM the start of the section)

 %define BASE_OF_SECTION SOME_CONSTANT_YOU_SHOULD_KNOW
isr_label:
   iret
 good_stuff dw (BASE_OF_SECTION + isr_label - $$) & 0xFFFF
            dw 0xcafe
            dw 0xbabe
            dw (BASE_OF_SECTION + isr_label - $$) >> 16

The role of

BASE_OF_SECTION

is to adjust the pure offset to the real situation (usually as defined in your linker script), e.g. if your kernel get loaded at 1MB, you'll set it to 0x100000 to keep the CPU happy.

Assembly Examples

NASM

This example is made for x86 CPUs running in IA32 mode (32-bit).

 int_handler:
    mov ax, LINEAR_DATA_SELECTOR
    mov gs, ax
    mov dword [gs:0xB8000],') : '
    hlt
 
 idt:
    resd 50*2
 
 idtr:
    dw (50*8)-1
    dd LINEAR_ADDRESS(idt)
 
 test1:
    lidt [idtr]
    mov eax,int_handler
    mov [idt+49*8],ax
    mov word [idt+49*8+2],CODE_SELECTOR
    mov word [idt+49*8+4],0x8E00
    shr eax,16
    mov [idt+49*8+6],ax
    int 49

should display a smiley on the top-left corner ... then the CPU is halted indefinitely.

GNU Assembler

This example sets up an interrupt handler in long mode.

.text
int_handler:
    movq $0x123abc, 0x0 // this places magic value "0x123abc" at the beginning of memory
    hlt

.p2align 4
idt:
    .skip 50*16

  idtr:
    .short (50*16)-1
    .quad idt

.globl do_test
do_test:
    lidt idtr
    movq $int_handler, %rax
    mov %ax, idt+49*16
    movw $0x20, idt+49*16+2 // replace 0x20 with your code section selector
    movw $0x8e00, idt+49*16+4
    shr $16, %rax
    mov %ax, idt+49*16+6
    shr $16, %rax
    mov %rax, idt+49*16+8
    int $49

This example differs from the previous one: it will not touch the screen, but will write the value "0x123abc" to 0x0 memory address and halt. It may be useful when there's no screen or BIOS available.

Problems with IDTs

Many of us while OS dev'ing will encounter a problem with IDT's. Here are some solved problems with IDT's

This is for solved problems. The unsolved ones can be found here on the Forum

Problems

Please post Completed problems here.

First of all, check your GDT.

Keyboard handlers need to actually read the scancode from port 0x60—it's not enough to just have the handler print something to indicate success and then send EOI. The symptoms are identical to forgetting to send EOI.

IDT problems in Assembly

Make sure the structure is correct and you are using linear addresses.

FASM notice

Since FASM doesn't accept the normal way as described above, I will describe it. FASM does, however, support shl and shr, so to describe the higher part of an ISR address, we just use label shl 0x10 where label is the name of the ISR. To define the higher part, we need to write a little more, since fasm use 64 bit, before compiling. This means that IF we just shl and shr, it will be that same as before. This is how we are supposed to do: (label shl 0x30) shr 0x30 Here is a little example, so you can see how it works:

 idt:
  dw  ((isr1 shl 0x30) shr 0x30)        ; the low part of the address
  dw   0x8    ; selector
  db   0
  db   010001110b  ; type
  dw (isr1 shr 0x10) the high part of the address
 
 isr1:
  mov ax,0xdead

See Also

Articles

• IDT
• IDT Problems