Pentium III exception on PI

[Peter_Vigren]

Hi, when I added exception handling (well, it prints the mnemonic and halts) to my protected mode thingy I noticed the weirdiest thing.

Exception 19 (13h), which is the Streaming SIMD Extensions fault that was added on the Pentium III, is halting my thingy. And this is on a Pentium I.

I don't understand why I get this exception... Any clues?

[Pype.Clicker]

uh ? maybe you should light a circle of candles and try to get the devil out of your motherboard ...

No clue to give ... i didn't even know about that "SIMD exception" ...
How do you know the exception number ? are you sure you're not mixing it with int 0x0D (13d) which is the General Protection Fault ?

[Peter_Vigren]

uh ? maybe you should light a circle of candles and try to get the devil out of your motherboard ...

No clue to give ... i didn't even know about that "SIMD exception" ...
How do you know the exception number ? are you sure you're not mixing it with int 0x0D (13d) which is the General Protection Fault ?

Yeah maybe... It's freaky...

I have reserved the first 19 exception and made a routine to print out their mnemonic (from that third Intel-pdf). XF is showing on the screen and that's the mnemonic (whatever that means) for exception 19 (13h).

[Pype.Clicker]

i would suggest you to print out that exception reporting function and to check with care it performs as it should ... among other things, check you didn't forget error codes, etc. and where the exception code come from ...

if it's not too large, you might attach the code ...

[Peter_Vigren]

i would suggest you to print out that exception reporting function and to check with care it performs as it should ... among other things, check you didn't forget error codes, etc. and where the exception code come from ...

if it's not too large, you might attach the code ...

I have extracted the exception handler and the IDT into the attached file. I can't find any programming error (not saying that there isn't one)...

[attachment deleted by admin]

[Peter_Vigren]

I'm sooo stupid! You were right, Pype.Clicker. When I was looking through the code I saw that the IDT was wrong. It is the General Protection Fault that is triggered.

It occurs when I use a) ret or b) iret. Why does the return trigger a GPF??

[Therx]

You need to save the registers before anything else in the ISR so that when you return to the program/kernel/whatever afterwards everything is the same. You can do this by pusha at the start and popa at the end. I'm not sure but you my also need to push and pop other registers. Here's my ISR code:-

Code: Select all

push gs                          ; Store all registers on stack
   push fs
   push es
   push ds
   pusha
   mov ax, GDT_DATA                 ; Set registers to known values
   mov ds, eax
   mov es, eax
   mov fs, eax
   mov gs, eax
   mov eax, %1
   push eax
   mov eax,_inthand
   call eax
   pop eax
   popa                             ; Restore all registers
   pop ds
   pop es
   pop fs
   pop gs
   iret

[Peter_Vigren]

You need to save the registers before anything else in the ISR so that when you return to the program/kernel/whatever afterwards everything is the same. You can do this by pusha at the start and popa at the end. I'm not sure but you my also need to push and pop other registers. Here's my ISR code:-

Code: Select all

push gs                          ; Store all registers on stack
   push fs
   push es
   push ds
   pusha
   mov ax, GDT_DATA                 ; Set registers to known values
   mov ds, eax
   mov es, eax
   mov fs, eax
   mov gs, eax
   mov eax, %1
   push eax
   mov eax,_inthand
   call eax
   pop eax
   popa                             ; Restore all registers
   pop ds
   pop es
   pop fs
   pop gs
   iret

But I push and pop the things I change already... and I do that in my routine that I call and try to return from too...

[Curufir]

I'm sooo stupid! You were right, Pype.Clicker. When I was looking through the code I saw that the IDT was wrong. It is the General Protection Fault that is triggered.

It occurs when I use a) ret or b) iret. Why does the return trigger a GPF??

Most likely cause is an invalid code segment being popped off the stack. So it sounds like you've trashed the stack somewhere along the line.

Go check to make sure ESP and SS contain good values when the ret/iret occurs (Ie work through and count stack operations by hand).

Shot in the dark, but I don't see you popping the error codes certain interrupts push on the stack, so your stack pointer would end up being wrong when you reach the iret. Odd though, because those interrupts are quite rare.

[Peter_Vigren]

I'm sooo stupid! You were right, Pype.Clicker. When I was looking through the code I saw that the IDT was wrong. It is the General Protection Fault that is triggered.

It occurs when I use a) ret or b) iret. Why does the return trigger a GPF??

Most likely cause is an invalid code segment being popped off the stack. So it sounds like you've trashed the stack somewhere along the line.

Go check to make sure ESP and SS contain good values when the ret/iret occurs (Ie work through and count stack operations by hand).

Shot in the dark, but I don't see you popping the error codes certain interrupts push on the stack, so your stack pointer would end up being wrong when you reach the iret. Odd though, because those interrupts are quite rare.

I will check the code for some stack operation I might have missed...

The exception handler isn't supposed to try to save the system at this time, it will just halt the computer (will work out something better in the future) and then it doesn't need to pop any error codes...

[Peter_Vigren]

Thanx for leading me right... It had to do with the fact that Esp hadn't been initialized... Now it works! *happy*