OSDev.org

Okay, thank you for explaining that. I will look into remapping the PIC and PIT. I appreciate all of you taking the time to set me straight in my confusion.

Also, I am using GRUB simply for ease. I have another friend who has written a working kernel (which didn't get very far), and he wrote his own bootloader, which he regrets simply because it was difficult. Perhaps someday I will write a bootloader, but right now I just want a simple functioning kernel.

As far as this interrupt goes, I think I should clarify one more thing. GRUB set CLI at some point. There was a long period of time where interrupts were turned off, while GRUB loaded your kernel. Part of that time may have been spent in Real mode, with the BIOS running, and part in Pmode. During that time, many interrupts may have happened -- and they may have been in a BIOS context, or in a Pmode context. You will never know. All those interrupts were "saved up". When you issue the STI command, you will suddenly receive ALL of them. The PIT is IRQ0; so it is the highest priority; so you will almost certainly receive that one first. At the moment that you issue STI you had better have an absolutely complete Pmode IDT set up, to handle all of them. It can be filled with function stubs that only send EOIs to the two PICs, but it needs to exist, and it needs to be functional -- and the LIDT command already must have been executed. Do not send an STI until you have done this.

edfed wrote:page fault means try to access a page that doesn't exists.
did you enable paging?
did the grub set a set of page tables?
why do you use grub to load your first DIY OS?
the best way to understand the PM at BOOT is to make it without any external intervention.

bosch is very dumb (and slow), it don't handle interupts correctly, my keyboard IRQ @ 21h is not executed at all with bosch, but in real boot ( from 386 to PIII ) , it works very good.

could an interrupt "trick" bochs into thinking that it is a GPF when it is actually something else?

yes.

Well, you have a problem with your keyboard handler then, mine works perfectly on real hardware (up to amd64 x2) and in bochs. Might want to double check that you are clearing the keyboard buffer after you enable interrupts, if you don't, the interrupt will never fire. don't blame bochs, blame yourself. Bochs is not dumb, it doesn't things correctly, if it works on real hardware, and not in bochs, you probably did something wrong and real hardware just isn't as picky. Bochs IS slow, it is meant to be, you are emulating all the hardware in a PC, and translating each opcode. Of course it's going to be slower than real hardware, it's for debugging purposes, and it does a good job at that (and no I am not affiliated with bochs in any way, and I have also had issues where it worked on real hardware and not bochs, it was my code, not bochs, the real hardware was more forgiving to mistakes).

Yes , bewing is correct, pleas leave interrupts disabled until you can handle them. It's opening a can of worms (like you've found) if you don't. An interrupt may have happened at any time since the bootloader was started, and it will wait until they are restored to fire, so you do a sti, and it fires, even though you didn't cause it, you still must be able to handle it.

Lastly yes, you can disable only PIC interrupts, simply do this:

mov al, 0xff
out 0xa1, al ;Disable slave PIC interrupts
out 0x21, al ;Disable master PIC interrupts

They typically start out disabled, but it won't hurt to do so yourself (or not enable interrupts until those are handled as well).

Just wanted to let you all know - you were completely right. The "error" was not a GPF but simply the PIT firing .

Glad your problem is fixed and I hope you learned a few things in the process .