OSDev.org

My keyboard handler is triggering a general protection fault. I'm in pmode, and I'm handling IRQ1.

I initially thought it was a paging thing, so I disabled paging. Then I thought it might be a segmentation thing, so I put it in flat memory mode. I thought it was a memory-related thing because I seemed to have the same problem drawing to the screen, but it turned out to be a different problem.

I switched to a static keybuffer and such, and my ISRs for exceptions (ex., GPF) work. I tried switching the order of the PIC master and slave EOI signals to match what I saw in a tutorial. I tried a CLI at the beginning of the ISR and an STI at the end. I tried malloc()ing a stack and setting the stack pointer to it. I tried having a static stack inside the function and setting the stack pointer to it.

Unfortunately, I can't include code here, since at this point it could really be anything. However, if you need more info about the code in question, the whole source distribution is available from http://projectxana.twilightparadox.com/xana.tgz

If anyone can think of even possibilities of what could be going wrong, please tell me.

Thanks,

~John

Make it easy for yourself: when you enter the GPF handler, store all registers (EIP, CS and EFLAGS you already have ofcourse) and then have your GPF handler print those for you.

Alternatively you could put CLI;HLT (as inline asm) in various places in your code, and see if it makes that far, then run in Bochs and break it when it says you run into a HLT with interrupts disabled, and sanity check all the registers it dumps. If you have the Bochs debugger enabled, you can use XOR BX,BX in the beginning of your GPF handler to break into the debugger, and look into the stack to see where you came from (what was the EIP it pushed) and then use objdump (or your favourite disassembler) to see what code you have at that address.

If Bochs bochs doesn't resets on CLI;HLT, use the following line (or add the option after your current cpu line) in your bochsrc:

Hm. I guess I could use my kernel_assert (which prints out an error and does a cli; hlt) to determine where in the keyboard handler it's GPFing. That's probably not going to tell me much, as I only have maybe 3 calls in said handler and i've tried swapping out all of them.

Are you sure you GPF in the handler, and not like for example in the IDT?

I mean do you actually get output if you try to print something from the keyboard handler or something?

The GPF handler works fine, so I don't imagine it's the IDT that's dead (since the part that tells me GPF is, of course, in the IDT).

Do you remap the PIC correctly? Looks so, mostly.
Also, it seems you don't have an IDT entry for the timer interrupt...

I imagine I remapped it correctly, though I'm not sure. Certainly, when I went to enable it, I used the right number. Is there a transform between when it's enabled and when it's set (assuming setting it uses the remapped values ?

Oh, and yeah -- no timer interrupt enabled. I'll set that up when I set up multithreading

Thinking that maybe not having the irq0 setup killed it, i set up a blank irq0 handler (no EOI or anything). That one doesn't trigger GPF though. I don't get it.

Hi,

hakware wrote:The GPF handler works fine, so I don't imagine it's the IDT that's dead (since the part that tells me GPF is, of course, in the IDT).

If the GPF handler works fine, then it should tell you what EIP was when the GPF occured and give you an error code that can help determine the problem.

If your GPF isn't implemented, just use a JMP $ as your GPF handler and use Bochs debugger examine the error code and EIP that the CPU pushed on the GPF handler's stack.

Also, if the IDT limit is set too low you'll get a GPF when the CPU tries to start the IRQ handler but the GPF itself will still work. For e.g. if the IDT limit is set to 0xFF then all exception handlers will work and all interrupts above 32 will cause a GPF.


Cheers,

Brendan

Actually that sounds like it might be the problem... What would be the best limit to set?

Hi,

hakware wrote:Actually that sounds like it might be the problem... What would be the best limit to set?

I'd set the limit to 0x07FF - it makes the IDT large enough for 256 interrupts (which is the most you can use), and means you won't run out of space for large SMP servers (with multiple I/O APICS and IPIs).


Cheers,

Brendan

Ok, thanks ^^;

Heh. Still doesn't work.

I also tried rewriting the remapping to copy some existing code, as well as remapping after setting the IDT, and no luck. I'm sure it's something in the IDT itself. It seems a lot like the 0xff thing listed above, but that doesn't seem to fix it unfortunately. *sigh*

Any other ideas?

Should I take that as a no?