OSDev.org

I was developing a 32 bit PM OS. I have set up a working IDT and GDT. My SS value before switching to PM was 0x600. After switching to PM, i have set up CS, DS values. Now if I point SS to a GDT entry for a stack segment and if i execute an INT instruction, triple fault is the result(I have not implemented exception handler). I have set up a TSS containing SS0, ES0 values. I am invoking the interrupt from ring 0 itself. Any hint as to why this happens???

Interestingly, suppose i leave the SS value untouched after switching to PM(ie, SS = 0x600 in PM), the code works fine, no triple fault is generated when executing INT instruction. I can push and pop into the stack. But the SS doesnot point to a valid entry in the GDT (no GDT entry exists in my GDT at offset 0x600 * and still the code works... Any hints??

I have set up a working IDT and GDT

Experimental results say otherwise.

Try looking at the segment limit.

appusajeev wrote: Interestingly, suppose i leave the SS value untouched after switching to PM(ie, SS = 0x600 in PM), the code works fine, no triple fault is generated when executing INT instruction. I can push and pop into the stack. But the SS doesnot point to a valid entry in the GDT (no GDT entry exists in my GDT at offset 0x600 * and still the code works... Any hints??

The CPU caches the segment data - so if you set SS to 0x0600 in real mode, it should behave like a 16-bit segment with base 0x6000, limit 0xFFFF - even if you're not in real mode any more. That's why you need to explicitly reload all segment registers once you're in protected mode.

Thanks for the replies.
I was in QEMU all this time. Now, lemme try this is real machine and see if its the prob with QEMU

You really must be new to programming in general to simply blame your tools.

Real hardware doesn't just crash, it even thinks it's funny not telling you why. Which is why the lot of us tests in qemu and bochs until that works before even considering real hardware

I used to try my os on an eeepc 900... until it died some month ago for the code executed in a "dirty" ram section. It has never worked again... It seems that something inside has been broken.

This is to say that perhaps if it doesn't work on the emulator... it could be a reason