OSDev.org

catOS wrote:I think I now have a General Protection Fault caused by a invalid opcode (I'm not sure), here's the log anyway

Oh come on, learn to read. I didn't write that litany last time for you to marvel at my knowledge, I actually did that so you could understand these outputs.

What do we have this time? v=06. As you have rightly identified, that is an undefined opcode exception. However, the instruction address here looks strange to me. 1bf is in the middle of the real mode IVT, which contains only data, not code. Is it possible that your IDT descriptor for the interrupt contained that address (or something before that) as handler address?

My first thought when I see execution from a nonsense address is that the kernel's main function returned to its caller, and the caller isn't handling it correctly.

The HLT instruction does not stop the CPU forever.

Octocontrabass wrote: The HLT instruction does not stop the CPU forever.

Interestingly when I comment out the hlt instruction, the system goes in a boot loop obviously but it's running keyboard interrupt handler code on each boot loop.

Well, yeah. If you don't stop the CPU at all, it'll keep going. It sounds like the code for your keyboard interrupt handler happens to be what's next in memory.

Octocontrabass wrote:Well, yeah. If you don't stop the CPU at all, it'll keep going. It sounds like the code for your keyboard interrupt handler happens to be what's next in memory.

oh I see, so do you know what's causing the triple fault?

You're not stopping the CPU, so the CPU keeps running until it hits garbage and triple faults.