OSDev.org

Hi I'm trying to make my own interrupt handler (first time I ever do that) but I'm struggling to get it working

To test if the problem was the C part, I added a 'call panic' command right at the beggining of every isr, but I still don't get anything

The code I got if made of some parts from the wiki and from a french website about osdeving.

Here is the code (please don't kill me if it's sh*t xD):

idt.c


idt.h


idt_loader.asm


interrupt_handler.asm


Hope someone cal help me

Mask interrupts? http://wiki.osdev.org/8259_PIC#Masking

Enable interrupts (sti)?

Thanks for answering

What a stupid mistake xD

I called sti after loading idt, and, It seems to work ! BUT when any interrupt is called, the vm reboots

probably something like...

IRQ0 (or similar) -- no handler
Double Fault -- no handler
Triple fault -- reboot

Fill in all the exceptions and faults in the IDT so you have something to work with.

I already assign an isr to every interrupt :/ It's done in the loadIDT() function:

You don't need an ISR for every interrupt. You need 32 ISRs for 32 different exceptions and other 224 entries for 244 interrupt request handlers. You should also remap your Programmable Interrupt Controller (PIC) so your exceptions don't interfere with your interrupt request handlers. When an exception occurs you should probably display something similar to a BSOD, halting the CPU if the kernel couldn't be recovered. I would suggest you taking a look at assembly macros for easier code management, you don't need to prototype all those entries by hand. Also don't forget about call gates if you are planning on using and IDT and interrupts for system calls. Those will probably have different flags and selectors. Every interrupt request should/could have a different handler (common assembly handler + different C handler scheme).

Before doing all of this, I think it would be better to have working interrupts

One thing I know, is that it's not related to the loading of the IDT, it only happens when I run 'sti' :/

Ok, let's walk through this a bit more... Maybe we can get there.

When you execute the 'sti' opcode, you are enabling interrupts. If you are experiencing a reboot right after that statement (I'm sure you have a debug statement in your code so you know this rather than presume), then you are getting an interrupt immediately. 'sti' alone will not cause a reboot.

Now. We know we are having a problem related to an interrupt. The causes are that the IDT is not set up (which it is as you indicate) or the IDT is set up incorrectly (a possibility, and generating a GPF) or it might be an alignment problem (but I cannot confirm it will manifest itself right after sti). Continuing down this line, if the interrupt or GPF is not handled properly, then you will get a Double Fault and if that is still unhanded a Triple Fault which leads to a reboot.

Now, if you have a common handler set up for all interrupts and that common handler is never called (a panic function call first thing as you mentioned), then you have to assume that the interrupt is never getting to the interrupt handler code. I would look into idt_entry() in particular and bit-map all the values you are setting -- like Present...?

Ok, thank you for answering I'll definitly check the structures tomorow !

I was wondering if the problem could be related to the GDT since I also created the functions to load it myself :/