Bipman wrote:
You were right, it was another interrupt. I created a GPF handler plus system error handler and it was the GPF that fired. I'm now trying to find out what caused the GPF but not sure how I find out.
Bipman
Check the stack, what did the #GP push there? There should be CS:EIP for the instruction that caused the #GP as well as an error code, either it's zero or a segment selector.. You can disassemble your binary and check which instruction exactly caused the #GP. If you can't solve it, copy some of the disassembly with the contents of the stack (the #GP pushed error code and CS:EIP)..
From WikiQuote:
General Protection Fault
A General Protection Fault may occur for various reasons. The most common are:
Segment error (privilege, type, limit, read/write rights).
Executing a privileged instruction while CPL != 0.
Writing a 1 in a reserved register field.
Referencing or accessing a null-descriptor.
The saved instruction pointer points to the instruction which caused the exception.
Error code: The General Protection Fault sets an error code, which is the segment selector index when the exception is segment related. Otherwise, 0.
Finally, I would recommend creating a single exception/interrupt handler that does nothing but print something like "unhandler interrupt/exception" and then halts and in the IDT put all the entries you have pointing to that. That way you always catch them and you'll know that something went wrong (ie. you didn't expect it). Later when you have the time just add valid exception handlers and leave the "generic" one handling the rest, hopefully at some point you have handlers for everything.
You might also want to improve on that a bit by making it print relevant regs, maybe the interrupt/exception number that occurred, possible error code, etc. If you don't print that stuff then everything that goes to the generic handler is indistinguishable, but even still at least you know something went wrong and can keep adding handlers one by one. Choice is yours =)
Note: I intentionally included interrupts and exceptions, I'm guessing quite a few have been bit early in their development by unintentionally enabling interrupts and then PIT or something else generates interrupt and everything just goes crazy for no apparent reason. Related to this last part it's worth remembering that until you re-map the PIC you have no (easy) way of knowing whether something is caused by an IRQ or exception as by default they overlap..