OSDev.org

After sti instruction a 0x0000000D interrupts appear causing triple fault. pic is doing okay, only keyboard is initialized, but still it is like that. It was 0x00000008 interrupt earlier, but something? changed and it just doesn't work. I want my keyboard working!
Source: https://github.com/nergzd723/tyler

Your code has a lot of mistakes, I'm not sure which one is causing the crash.

Interrupt 0x08 and 0x0D are not IRQs, they are CPU exceptions. The first 32 interrupts are reserved for CPU exceptions. You will need to reprogram the PIC because it will try to use some of those reserved interrupts for IRQs, and you won't be able to tell the difference between an IRQ and an exception.

Some exceptions have error codes. You see the "push dword 0" in all of your interrupt handler stubs? Many tutorials use that as a placeholder for the error code for exceptions that don't have error codes, so the same interrupt handler routine can run whether the exception pushes an error code or not. You must remove that line from the interrupt handler stubs that belong to exceptions with error codes.

When it's time to return from your interrupt handler with IRET, you need to clean up the stack. That "add esp, 8" line you've commented out removes the interrupt number and error code from the stack. Without it, all of your interrupts will cause a crash.

You're not obeying the C ABI, so the C code in your interrupt handler is clobbering the contents of the stack. This can cause the interrupted program to crash.

GRUB loads your OS in protected mode with the A20 line already enabled, so you don't need code to switch to protected mode or enable A20. You still need code to reload segment registers. Don't forget RET at the end of your functions!

These are just problems I've spotted from looking at your code for a few minutes. Perhaps you are not yet ready to write an OS.

Octocontrabass wrote:Your code has a lot of mistakes, I'm not sure which one is causing the crash.

Interrupt 0x08 and 0x0D are not IRQs, they are CPU exceptions. The first 32 interrupts are reserved for CPU exceptions. You will need to reprogram the PIC because it will try to use some of those reserved interrupts for IRQs, and you won't be able to tell the difference between an IRQ and an exception.

Some exceptions have error codes. You see the "push dword 0" in all of your interrupt handler stubs? Many tutorials use that as a placeholder for the error code for exceptions that don't have error codes, so the same interrupt handler routine can run whether the exception pushes an error code or not. You must remove that line from the interrupt handler stubs that belong to exceptions with error codes.

When it's time to return from your interrupt handler with IRET, you need to clean up the stack. That "add esp, 8" line you've commented out removes the interrupt number and error code from the stack. Without it, all of your interrupts will cause a crash.

You're not obeying the C ABI, so the C code in your interrupt handler is clobbering the contents of the stack. This can cause the interrupted program to crash.

GRUB loads your OS in protected mode with the A20 line already enabled, so you don't need code to switch to protected mode or enable A20. You still need code to reload segment registers. Don't forget RET at the end of your functions!

These are just problems I've spotted from looking at your code for a few minutes. Perhaps you are not yet ready to write an OS.

Thank you! Yep, maybe I am not ready to write a OS. But I've read a lot of info and saw a lot of examples. I don't code on C well but I just want to do that. It's like challenge to me. I understood that I really like low-level after all. Will try to fix errors. Or maybe rewrite it(not a big deal). But I saw something strange: before sti it WAS the GDT and IDT, and after it it just disappears. I think it is really strange. Maybe when CPU exception occurs, it resets the adresses of IDT and GDT? Cause BOCHS says that their base is the same.
Then,enabling line A20 and entering Protected Mode is because I don't usually use GRUB and don't want to. I use direct multiboot kernel execution in QEMU.
And the last: why do QEMU don't stop on triple fault?

nergzd723 wrote:I don't code on C well but I just want to do that. It's like challenge to me.

C is a very difficult language to learn correctly. Unlike many other languages, it has very little error detection. If you write bad code, the compiler may not warn you. If you're lucky, your program will crash to tell you you've made a mistake. If you're not, your program will appear to work fine - until it doesn't, and you have no idea why.

Trying to learn C while developing an operating system will certainly be a challenge, but it may be wise to get some experience developing userspace programs in C first.

nergzd723 wrote:But I saw something strange: before sti it WAS the GDT and IDT, and after it it just disappears. I think it is really strange. Maybe when CPU exception occurs, it resets the adresses of IDT and GDT? Cause BOCHS says that their base is the same.

A triple fault resets the CPU to its power-on defaults (mostly). If you're looking at the GDTR/IDTR after the triple fault, that's why.

nergzd723 wrote:Then,enabling line A20 and entering Protected Mode is because I don't usually use GRUB and don't want to. I use direct multiboot kernel execution in QEMU.

QEMU loads your OS in protected mode with the A20 line already enabled, so you don't need code to switch to protected mode or enable A20.

Perhaps you should read more about multiboot.

nergzd723 wrote:And the last: why do QEMU don't stop on triple fault?

Ask the QEMU developers.

why do QEMU don't stop on triple fault?

Try using the parameters:

-monitor stdio -no-reboot -no-shutdown

This should let you inspect the machine state in the monitor.