OSDev.org

Posted: **Wed Jun 27, 2012 11:01 am**

hello guys, i too got similar error. i don't know why. i have done

   isr_h:
   pusha                    ; push edi,esi,ebp,esp,ebx,edx,ecx,eax

   mov ax, ds               ; Lower 16-bits of eax = ds.
   push eax

   mov ax, 0x10  ;kernel data segment descriptor
   mov ds, ax
   mov es, ax
   mov fs, ax
   mov gs, ax
   mov ss, ax

   call isr_handler

   pop eax        ;original data segment descriptor
   mov ds, ax
   mov es, ax
   mov fs, ax
   mov gs, ax
   mov ss, ax

   popa
   add esp, 8
   sti
   iret

and for setting gdt

Code: Select all

gdt_set_2:
     mov eax,[esp+4]
     lgdt [eax]
     mov ax, 0x10
     mov ds, ax
     mov es, ax
     mov fs, ax
     mov gs, ax
     mov ss, ax
     jmp 0x08:.flush
.flush:
     ret

Code: Select all

00044166318e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x08)
00044166318e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x0d)
00044166318e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x08)
00044166318e[CPU0 ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting
00097560109e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x20)
00097779809e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x20)

in my kernel code itself i made such that it should halt when exception (in this case general protection fault) occurs. so what i could see is that it didn't occur as son as idt was set up and i did asm("sti"::); but a little while later gpf occurs. from many days i am stuck with this.

one last thing, in bochs how to know that contents of stack. i have a doubt that i might have some stack problem or so because i felt that the values i gave for gdt descriptors was proper.

Posted: **Wed Jun 27, 2012 12:22 pm**

[Note: this reply does not belong to Hedge's thread - the original thread appears to have been split at the point where it was gatecrashed by Hedge, and the part which my reply is a reply to appears to have disappeared into a black hole.]

sys_code: dw 0xFFFF, 0x0000, 0x9800, 0x00CF

The 98 looks odd. I can't be bothered digging up the details of what all the bits do, but most GDTs would use 9A instead. You should have the details at hand, so check it carefully to see if it matters.

Posted: **Wed Jun 27, 2012 8:52 pm**

Try the "info gdt <n>" command in the Bochs debugger, it will show you the GDT entry at index <n>

Posted: **Wed Jun 27, 2012 9:03 pm**

You are switching the stack to your kernel data segment, but keep using the current ESP value (assuming the CPL did not change?).

Then, when you do 'pop eax', you are taking some random value from the kernel stack, not the original value that you pushed before ( unless ss was equal to 0x10 when you started )

It's easier if you do not change SS.

It's also not clear to me why you add 8 to esp at the end, this may be why 'iret' does not find a valid CS descriptor on the stack, resulting in the error you mention. Lastly, iret restores EFLAGS from the stack too, so 'sti' at the end is unnesessary (and possibly wrong, depending on whether interrupts were disabled in the code you interrupted - possible if this routine is some kind of trap handler)

Posted: **Thu Jun 28, 2012 3:03 pm**

What's happened to the bulk of this thread? My earlier reply was to the original OP and not to the gatecrasher with a similar problem. It looks as if the thread's been split, as it should be, but the original thread appears not to have survived that operation.

Posted: **Thu Jun 28, 2012 10:09 pm**

The original thread was from about 2009 IIRC, and Hedge necro'ed it. With his post and everything after it (including your reply) moved to this thread, the original has probably fallen back a couple dozen pages.

Your reply technically does belong with that thread, but it also probably came three years to late to be of benefit to the OP, so it probably really doesn't belong anywhere. (Not that that's your fault. Once a thread has been necro'ed, it's really easy to miss the OP date and reply to an OP that's years old, and I've had it happen to me several times before).

Posted: **Fri Jun 29, 2012 12:11 pm**

Ah - found the original part by searching for "GDT borked". I was sure I'd seen that thread just the day before Hedge posted to it, but I can't possibly have. Anyway, I hope he learns to stop digging up ancient history and just ask his own questions in his own threads.

OSDev.org

Reset in protected mode

Reset in protected mode

Re: Reset in protected mode

Re: Reset in protected mode

Re: Reset in protected mode

Re: Reset in protected mode

Re: Reset in protected mode

Re: Reset in protected mode