another IDT problem <sigh>

[stonedzealot]

At the risk of seeming like more of an idgit (idiot's idiot) :-[ I'd like to post this question. I know something similar was talked about in ahdeelmahmood's post on problems with Xsism's IDTKernel. I read through that post and found no answers, only that his GPF loops were generated by the timer having no isr.

I guess that post just went straight over my head. I set up the idtr with all 256 entries, all handled by a single function that gets the int number as a pushed parameter. It handles three events, keyboard interrupt, timer interrupt and GPF directly and has a general handler for the rest.

I get infinite amounts of General Protection Faults (interrupt 13) from the timer as discussed in the post previously mentioned. Upon masking irq0 to stop the timer interrupts, the loop stopped...but as soon as the keyboard interrupt is fired another infinite amount of GPFs occur.

I'm positive that all of the idtr entries are covered and they all point to a valid handler...

Anyway, I'll post up the code:
http://www.geocities.com/stonedzealot/interrupt.c <-- the main interrupt handler code
http://www.geocities.com/stonedzealot/kernelstart.asm<-- the kernel start code
any other units you need to see, I'll post them up too

[distantvoices]

your isr expcts TWO values on the stack, not only the one you push onto it.

->masterinterupt(int xxx,int yyy) if i remember it right.

I recommend you push one value more to the stack. maybe it helps?

[stonedzealot]

Yes, the masterinterrupt at the moment has error code capability and no it's not handled well but the only reason I'd hesitate to blame that would be because when I had 256 individual functions imported into the ASM code and subsequently hooked into the IDTR (and nothing was pushed to the stack by me) it still gave me the huge GPF thing in exactly the same manner...mainly because the program never actually exits the function (that would be my best guess).