Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
init_gdt(); // goes well.. debuging didn't point any bugs
init_idt(); // the same for this one..
asm("sti"); // after this a GPF happens :@(6)
for(;;); // go and do infinitly nothing :p
I really have no idea why this happened.. A GPF when I'm just looping :S
I hope someone can help.
Sorry, but this has nothing to do with timer ints.. This should work since it worked for me before.. I only stripped the code out of my classes and converted it to normal C code.
I just looked at your code. What happens, when the timer interrupt fires? There doesn't seem to be an interrupt handler for that case, resulting in a GPF...
hmm i bet thats why my os gets a gpf after enabling interrupts and then going into an infinite loop
you also need to remap the pic because by default it starts at 8 which is also reserved for exceptions so it would be like everytime your timer rings it has an 8th exception
hckr83 wrote:
you also need to remap the pic because by default it starts at 8 which is also reserved for exceptions so it would be like everytime your timer rings it has an 8th exception
If you've read my source code carefully I already did that
XenOS wrote:I just looked at your code. What happens, when the timer interrupt fires? There doesn't seem to be an interrupt handler for that case, resulting in a GPF...
Though there is.. The interrupt is handled by the default handler int_unknown() which does only an iret (just lookup in my idt_init() function).. Shouldn't give a problem. Worked before.
Have you checked whether the compiler creates a stack frame for int_unknown? If so, the raw asm("iret"); causes a return to the pushed EBP register instead of the return address, resulting in a GPF.
XenOS wrote:Have you checked whether the compiler creates a stack frame for int_unknown? If so, the raw asm("iret"); causes a return to the pushed EBP register instead of the return address, resulting in a GPF.
That could be the cause of my problem.. Thanks.. I'll put it in a .asm file.. and test if it works
EOI wasn't needed to solve the problem.. I've put the function in a assembly file and assebled it with nasm.. linked it in my kernel.. and it works... But Now I've got another question (not a problem :p).. Is there an option in GCC to disable the creation of a stack-frame? (Was it the -fomit-frame-pointer option ??)
#define irqm_return __asm("pop %edx");__asm("pop %edx");__asm("pop %edx");outportb(0x20, 0x20);__asm("iret")
void irq0(){ /*overflow causes invalid opcode error, although that dont quite make sense*/
/*timer*/
if (timer_ticks>0xFFFFFFF5){timer_ticks=0;}
timer_ticks++;
irqm_return;
}
as i stated, for some reason UNDER BOCHS an overflow causes an invalid opcode error although i got no error with microsoft vpc and i got no error on my real pc