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!? (ASM)

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're 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 misimplementation 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 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 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. You need to have

 outb(0x20,0x20)

within any master handler and any

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

within any slave handler.

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 Example

 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.

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. Keep in mind padding issues. In C this goes like:

pragma pack(push, 1)
struct IDT_reg {
 //struct here
};
pragma pach(pop, 1)

IDT problems in Assembly

Make sure the structre 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

• IDT

• IDT problems