Page 1 of 1
isr8 - Double Fault and isr13 - General Purpose Exceptions
Posted: Sun May 29, 2011 6:32 pm
by shobhitsharda
Hi,
I have been working on 64 bit kernel development. I was able to enable interrupts, but while booting, my kernel is crashing after throwing Double Fault Exception(isr8) repeatedly when General Purpose Exception(isr13) is disabled. When I enabled General Purpose Exception(isr 13), my kernel is throwing General Purpose Exception repeatedly and is crashing.
I did some search regarding the conditions on which these exception occurs and understood that, it might be because of irq0 to irq15 which is mapped on the entries 8 to 15. Thus, I remapped the entries of irq0 - irq15 on IDT 32 to 47.
But the problem still persist. Can anyone help me in this regard.
Thanks in advance.
Re: isr8 - Double Fault and isr13 - General Purpose Exceptio
Posted: Sun May 29, 2011 6:58 pm
by NickJohnson
More likely, some other piece of code is causing a general protection fault, which your general protection fault handler does not fix. When the GPF handler is disabled, there is supposed to be a double fault; that's the purpose of a double fault.
Try printing the saved instruction pointer and register contents when a GPF occurs so that you can find and debug the faulting code.
Re: isr8 - Double Fault and isr13 - General Purpose Exceptio
Posted: Sun May 29, 2011 9:04 pm
by Chandra
I'm wondering if you're messing with the memory regions you're not supposed to. You may recheck your GDT to verify that you've proper access to the memory regions you're dealing with. Like NickJohnson said, the purpose of exception handlers is to trap the exceptions/faults and therefore, when you've turned off the exception handlers, the system double faults followed by a 'Triple Fault' and resets. That's how it is supposed to be.
You may also want to isolate the problem by tracking down the piece of code that is causing this problem. From there, you may be able to get a clue. Good Luck!
Re: isr8 - Double Fault and isr13 - General Purpose Exceptio
Posted: Tue May 31, 2011 4:35 am
by shobhitsharda
Hi,
Below is the portion of GDT written in .asm format. On checking the amd manuals, i have found that most of the fields of GDT in long mode are ignored and the only relevant fields are:
1. in code segment - D, L, P, DPL and C
2. in data segment - P
However, these fields are already taken care in the following code.
Thus, I am wondering where exactly am I going wrong.
FYI : To set up long mode I am referring
http://wiki.osdev.org/User:Stephanvansc ... _Long_Mode
Code: Select all
[BITS 32]
;setting up the long mode
;enable paging
lgdt [GDT64.Pointer] ; Load the 64-bit global descriptor table.
jmp GDT64.Code:start64 ; Set the code segment and enter 64-bit long mode.
[BITS 64]
SECTION .text
start64:
; initialize segment registers
mov ax, GDT64.Data ; Set the A-register to the data descriptor.
mov ds, ax ; Set the data segment to the A-register.
mov es, ax ; Set the extra segment to the A-register.
mov fs, ax ; Set the F-segment to the A-register.
mov gs, ax ; Set the G-segment to the A-register.
; initialize 64bit stack pointer RSP.
mov rsp, _sys_stack-4
extern main
call main
hlt
GDT64: ; Global Descriptor Table (64-bit).
.Null: equ $ - GDT64 ; The null descriptor.
dw 0 ; Limit (low).
dw 0 ; Base (low).
db 0 ; Base (middle)
db 0 ; Access.
db 0 ; Granularity.
db 0 ; Base (high).
.Code: equ $ - GDT64 ; The code descriptor.
dw 0 ; Limit (low).
dw 0 ; Base (low).
db 0 ; Base (middle)
db 10011000b ; Access.
db 00100000b ; Granularity.
db 0 ; Base (high).
.Data: equ $ - GDT64 ; The data descriptor.
dw 0 ; Limit (low).
dw 0 ; Base (low).
db 0 ; Base (middle)
db 10010000b ; Access.
db 00000000b ; Granularity.
db 0 ; Base (high).
.Pointer: ; The GDT-pointer.
dw $ - GDT64 - 1 ; Limit.
dq GDT64 ; Base.
Thanks for helping.
regards,
Re: isr8 - Double Fault and isr13 - General Purpose Exceptio
Posted: Tue May 31, 2011 6:03 am
by gerryg400
The books aren't exactly clear on this.
I'm going by memory a bit here but I'm pretty sure that the processor does an IRET in long mode the SS popped off the stack must be a writeable data segment.
Change the access bits to 0x92 to make the data segment writable and load the SS as well.
[Edit] Just checked doc Intel 2A for IRET. #GP(selector) if the stack is not a writable data segment.