More Tripple Faults
Re:More Tripple Faults
Probly because your IDT is bad...Perica has a good asm IDT......but i'm looking at your code....
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:More Tripple Faults
Code: Select all
; Now patch the IDT Entries
mov ecx, 47
mov bx, [IDT_location + 2]
.IDT_Patch mov ax, [linear_cs]
add word [bx], ax
add bx, 8
loop .IDT_Patch
Second, you should take care of the case when add word[bx],ax would overflow and perform adc [bx+6],0 aswell.
Re:More Tripple Faults
I have changed it to this to get rid of over flow but I still get tripple faults
; Now patch the IDT Entries
mov ecx, 47 ; Therea are 47 Ints
lea ebx, [IDT] ; Get the position of IDT
.IDT_Patch mov edx, [linear_cs] ; Get that value to patch with
xor eax, eax
mov ax, word [ebx] ; Get current value
add eax, edx ; Convert it to linear
mov word [ebx], ax ; Set Value with lower half
shr eax, 16 ; bring higher half into ax
add ebx, 6 ; Go to the higher offset in Entry
mov word [ebx], ax ; set it
add ebx, 2 ; Goto Next IDT Entry
loop .IDT_Patch
; Now patch the IDT Entries
mov ecx, 47 ; Therea are 47 Ints
lea ebx, [IDT] ; Get the position of IDT
.IDT_Patch mov edx, [linear_cs] ; Get that value to patch with
xor eax, eax
mov ax, word [ebx] ; Get current value
add eax, edx ; Convert it to linear
mov word [ebx], ax ; Set Value with lower half
shr eax, 16 ; bring higher half into ax
add ebx, 6 ; Go to the higher offset in Entry
mov word [ebx], ax ; set it
add ebx, 2 ; Goto Next IDT Entry
loop .IDT_Patch
Re:More Tripple Faults
I would just use C to set up the descriptors, my c function is as follows:
My IDT struct is as follows:
I initially set them all up to point to a generic ISR that just prints out a message.
Code: Select all
void Descriptor_SetInterruptGate( uint32 nInterrupt, void *pHandler ) {
Kg_sKernel.m_sIDT[ nInterrupt ].m_nSelector = 0x08;
Kg_sKernel.m_sIDT[ nInterrupt ].m_nBaseLow = ( ( uint32 ) pHandler ) & 0xFFFF;
Kg_sKernel.m_sIDT[ nInterrupt ].m_nBaseHigh = ( ( uint32 ) pHandler ) >> 16;
Kg_sKernel.m_sIDT[ nInterrupt ].m_nFlags = 0x8E00;
}
Code: Select all
typedef struct {
uint16 m_nBaseLow;
uint16 m_nSelector;
uint16 m_nFlags;
uint16 m_nBaseHigh;
}
K_sIDT_t;
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:More Tripple Faults
You're doing 47 iterations and each of them process one IDT entry! you should set ecx to ((IDT_end-IDT)/8)-1.srg wrote: I have changed it to this to get rid of over flow but I still get tripple faultsCode: Select all
; Now patch the IDT Entries mov ecx, 47 ; Therea are 47 Ints lea ebx, [IDT] ; Get the position of IDT .IDT_Patch mov edx, [linear_cs] ; Get that value to patch ... loop .IDT_Patch
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:More Tripple Faults
1. remember some exceptions require you to pop the error code from the stack before you IRET' them ...
2. remember also that directly returning from an exception is unlikely to solve it ... a "hlt" is more likely to help you for now
3. you cannot just change AL value in an interrupt and return. You *must* do a push eax / pop eax or you'll see eax's value changing randomly from your main program.
4. doing a memory read between setting CR0.PE=1 and setting DS to the data descriptor value is an subtle invokation of #GPF
5. you should CLI before you start all the pmode switching job ...
6. better try your interrupts work with INT 0x30 before you enable hardware interrupt requests again.
2. remember also that directly returning from an exception is unlikely to solve it ... a "hlt" is more likely to help you for now
3. you cannot just change AL value in an interrupt and return. You *must* do a push eax / pop eax or you'll see eax's value changing randomly from your main program.
4. doing a memory read between setting CR0.PE=1 and setting DS to the data descriptor value is an subtle invokation of #GPF
5. you should CLI before you start all the pmode switching job ...
6. better try your interrupts work with INT 0x30 before you enable hardware interrupt requests again.
Re:More Tripple Faults
Also...make your exces print a message and cli/hlt so you can see if there is a GPF going on or a stack thing or whatever....
Re:More Tripple Faults
Do the cli and sti Instructions only stop hardware Interrupts, or do they stop the exceptions as well?
Re:More Tripple Faults
I belive they only stop the ones you made....since I still get exceptions ( tripple fault ) when there are bugs in my kernel before I enable interrupts
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:More Tripple Faults
only hardware interrupt requests are affected by IF.srg wrote: Do the cli and sti Instructions only stop hardware Interrupts, or do they stop the exceptions as well?
exceptions and software interrupts (INT nn) will still be handled.
Re:More Tripple Faults
BTW, is my PIC remapping code OK? It's an asm rewrite of the one in the FAQ
Re:More Tripple Faults
All my exception handlers now put a letter into the first byte of screen memory and then call a halt instruction. Also if they have an error code it's poped into eax.
The letter means I can reference it to the exception that called it.
But it tripple faults before I even get there.
I have tried with both calling an exception with the Int instruction and also using the sti instruction, but it just triple faults.
The letter means I can reference it to the exception that called it.
But it tripple faults before I even get there.
I have tried with both calling an exception with the Int instruction and also using the sti instruction, but it just triple faults.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:More Tripple Faults
that sounds more and more like a badly assembled bug ... i mean you might have some reference to the old CS-based offsets after you moved CS to be zero-based ...