OSDev.org

Of course I know it's avoidable... The bugger just seems to be persistent. Here's what I do:

1.) Bootloader enters pmode, loads kernel, and jumps to it.

2.) Kernel disables interrupts, sets up stack, cs, ds, etc. (all segment regs)

3.) Kernel sets up IDT (with a single ISR (# 0) ) and loads it into idt register

4.) Kernel outputs offset of ISR, outputs offset and contents of IDT, outputs offset and contents of ISR descriptor

5.) Kernel disables interrupts

6.) **Seemingly** unavoidable triple fault is thrown (exception 13)

Everything seems to be correct judging by the kernels output of the ISR, IDT table, and IDTdescriptor. Yet, the triple fault is thrown IMMEDIATELY after I issue an "sti" statement. Heres the output of the kernel, comment for your readability in my own special way:

Keep in mind that those bytes are stored in little endian. If you fix them visually, you can see that everything points to where it should.

Here is botchs log from the time I enter p-mode, to the time I triple fault: http://pastebin.ca/1507662

Thanks to bochs I now know what's that I have been triple faulting and that's the problem; with vbox I had absolutely no clue. However, I remain clueless to the cause of the triple fault... All help appreciated,

Brodeur235

Of course it will triple fault. As soon as you sti, the PIT fires. Because you havent remapped the interrupts, its int number 8.

Because there is no entry #8 in the IDT, it GPFs. Because there is no GPF handler it double faults. Because there is no double fault handler it will triple faults and reboot.

Cheers,
Gzaloprgm

Dude... You are a LIFE saver. Do you know how long I've been stressing over this? Over a week I've been stuck at the IDT. Suffice it to say that I'm excited, and thankful that you took the time to reply...

Brodeur235

(It works now... If you didn't already get that.)