Why does my OS crash when a IRQ1 gets issued?

NunoLava1998 · **Joined:** Sun Oct 09, 2016 4:38 am **Posts:** 273

I almost implemented minimal keyboard support into my OS. However, for some reason, my emulator (QEMU) likes to restart when it receives a IRQ1. This atleast means i'm processing a IRQ1 correctly (it also doesn't issue it 5624 times), it just seems to be crashing.
Yes, i still get 7's when i move my mouse. That happens in emulators when your mouse is PS/2. I still have to disable the mouse I/O port.

If you're hungry for my Github code (just updated), go:
https://github.com/NunoLava1998/DixiumOS

It compiles without errors, warnings on -Wall -Wextra.

How would i fix this problem?

PROGRESS:
implementing keyboard_handler (not the actual handler)
learning to receive IRQ1's
trying to call keyboard_handler only when a IRQ1 is issued.

iansjack · **Posted:** Tue Dec 20, 2016 1:56 am

I can't see any IDT in your code, which would explain why it triple faults as soon as an interrupt is received.

NunoLava1998 · **Joined:** Sun Oct 09, 2016 4:38 am **Posts:** 273

iansjack wrote:

I can't see any IDT in your code, which would explain why it triple faults as soon as an interrupt is received.

Is this the correct way of initializing the IDT?

Code:

struct IDTDescr{
   uint16_t offset_1; // offset bits 0..15
   uint16_t selector; // a code segment selector in GDT or LDT
   uint8_t zero;      // unused, set to 0
   uint8_t type_attr; // type and attributes, see below
   uint16_t offset_2; // offset bits 16..31
};


static inline void lidt(void* base, uint16_t size)
{   // This function works in 32 and 64bit mode
    struct {
        uint16_t length;
        void*    base;
    } __attribute__((packed)) IDTR = { size, base };

    asm ( "lidt %0" : : "m"(IDTR) );  // let the compiler choose an addressing mode
}

void load_lidt(void){
   lidt(32, 64);
}

The size of IDTDescr seems to be 64, and the size of Base is already described, 32.
Is this correct?

EDIT: it isn't

iansjack · **Posted:** Tue Dec 20, 2016 2:36 am

I would strongly recommend that you write assembler routines in pure assembler rather than trying to use in-line assembly, which can be rather complicated and i full of potential pitfalls. For example, in the line:

Code:

asm ( "lidt %0" : : "m"(IDTR) );  // let the compiler choose an addressing mode

what is the purpose of your coment "let the compiler choose an addressing mode"? Surely you want to specify the addressing mode for this instruction rather than leaving it up to the vagaries of the compiler.

NunoLava1998 · **Joined:** Sun Oct 09, 2016 4:38 am **Posts:** 273

iansjack wrote:

I would strongly recommend that you write assembler routines in pure assembler rather than trying to use in-line assembly, which can be rather complicated and i full of potential pitfalls. For example, in the line:

Code:

asm ( "lidt %0" : : "m"(IDTR) );  // let the compiler choose an addressing mode

what is the purpose of your coment "let the compiler choose an addressing mode"? Surely you want to specify the addressing mode for this instruction rather than leaving it up to the vagaries of the compiler.

I'm not that good at stuff in interrupts. Also, i don't seem to find any "addressing modes" related to IDT.

iansjack · **Posted:** Tue Dec 20, 2016 2:54 am

I believe that you are still just cutting and pasting code without any understanding of what it does and how it works. This is never going to work.

For example, it doesn't look as if you understand what a hardware interrupt is and how the processor responds to one. I think you need to do quite a bit more reading before you are ready for OS development. Hone your C, assembler, and debugging skills on user programs first and then you will be better equipped to deal with more advanced stuff. But until you have a firm grounding in C programming and debugging you are not going to progress.

OSDev.org

Why does my OS crash when a IRQ1 gets issued?

Who is online