OSDev.org

I was testing my beginning of OS (currently only a boot loader) in Bochs and all was perfectly working (mainly going in PMode, setting an IDT with working exceptions handlers, and putting something in the screen memory).

But I've had the idea of testing it on a real machine! And it reboot when, directly after far jumping into a 32-bit segment, I do a MOV SS,{a register containing a selector} or a MOV ESP,0. If I replace it by MOV DS,{same register} I am able to read and write from/to DS. The selector has base=0, granul.=1, limit=FFFFFh, non-system and R/W data type.
(I tested all of it with a JMP $)

What's the complete descriptor and what's the value of the selector? Did it work in Bochs?

I've tried 2 selectors:
A) selector=0x0010 (original version, which I would like to restore, many times tested on Bochs)

B) selector=0x0020 (to try with a 4GiB segment)

tempGDT.2:   struct descriptor,0xFFFF,0,0x08,10010010b,01000000b   ;stack
tempGDT.4:   struct descriptor,0xFFFF,0,0,10010010b,11001111b   ;data
(I use a 'struct' macro of my own, but all after 'descriptor,' is the descriptor data, zeroised if not present)

Have you tried using the data segment as the stack? Generally people only create 4 segments in the GDT, Kernel Code/Data and User Code/Data the stack is usually placed in the data segment.

The structs are missing the last byte of the base address but you are probably defaulting it to 0. The Segment is 0-64KB, is ESP actually in it? You mentioned doing 'mov esp, 0', that won't work, as soon as you push something on the stack ESP moves DOWN causing ESP to become negative/overflow which will cause a crash.

First would I say that when I wrote 'tested with Bochs' it means 'successful tested with Bochs'!

And secondly Yes: I tried with the Data segment. I've now tried something new: MOVZX ESP,SP while in Rmode, but no more result... HOW DO OTHER PEOPLE TO SET STACK IN PMODE?????

lss esp, [something] most of the time ...

I finally found the solution: I put a CLI a few lines before going into Pmode... It works now fine (and with the segments I wanted!), but I don't know why it doesn't before? What does CLI in addition to unsetting IF? And why does it work without CLI in Bochs?

Thank you 'AR'

It's because of the interrupts.

If a processor receives an IRQ from the PIT it checks the Interrupt descriptor table for the Interrupt request Number it has received: Remember - you are *remapping* the PIT to issue IRQ's for master starting with 0x20 and for slave starting with 0x28 - f. example. these are indices into the Interrupt descriptor table.

Now, what happens, if the processor canna find the IDT (it looks into the IDTR - Interrupt descriptor table register)? it generates an exception - and as the exception requires the very same Interrupt descriptor table as the hard ware interrupts, you are going to get a Triple Fault - and that's the point where our processor loses faith and simply resets ("pof that's too much I don't want anymore ...").

the reason why such weird things don't happen in the Bochs is: BOchs is an emulator, and depending from the interrupts you 've masked/the frequency you've set the timer irq to, sooner or later (I s'pose later) you gonna receive an emulated irq ... snaaaaaaaiiil like. On real hardware, life is more complicated and meanwhile easier, you won't believe it. Hardware just does what it's expected to (?hem ... sometimes), but Bochs does additional stuff besides the emulating - It logs stuff, does the debugging and so forth. It isn't the most accurate abstraction for hardware you gonna find, but heck it's for free as in free beer. ) Better still is qemu, and faster it is too.

It has happened to me too. Don't want to remember the hours I 've spent cursing because of not being able to find it out.

HtH & ccw