OSDev.org

Pype.Clicker wrote: 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 ?

Pype.Clicker wrote: 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 ...

Therx wrote: 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 wrote: 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??

Curufir wrote:

Peter_Vigren wrote: 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.