OSDev.org

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

Just to make sure, do you actually disable (or mask the IRQ) the PIT? Because by default it'll be giving you interrupts at some default rate and causing GPF it there's no IDT entry for whatever IRQ0 is mapped to.

edit: oh, and make sure you have a valid handler for IRQ7 and IRQ15 as well. At least for IRQ7. You could get so called spurious interrupts, and if there's no valid IDT entry, you can GPF from those as well. I'm not sure if those can actually get through even when IRQ7/IRQ15 are masked...

Easiest thing to do is to simply have a valid handler for each and every IRQ line. If you don't need said handler, just have it EOI the interrupt (so PIC doesn't get stuck with it).

Hmm. All the IRQs are masked except for 0 and 1, but it's definitely the keyboard interrupt that's killing it. Does the keyboard interrupt do any other interrupts after you EOI it or something? I'll try setting up all the interrupts, but i can leave it running for days and it doesn't GPF until I press a key.

Can you post the bochs log please.

Also can you please tell me where your keyboard drive code is (i've look almost everywere)?

I'm actually not using bochs -- I'm just testing this on a real system atm, though if I don't have one handy I use qemu.

The keyboard code is in src/klib/Stdin.d and the IDT code is in src/klib/idt.d . The PIC code is in src/klib/pic.d

Bochs probably gives the best debugging options and logs of all possible environments you could run your code in. You should definitely use it for debugging.

I have located your problem, the keyboard handler isn't being set (bochs reports an null descriptor). I'm not quite sure how D handles passing stuctures to function. But C, makes a copy of the variable (i.e if it's a pointer, it only copies the pointer rather than the memory it points to).

After doing some research, it is a I segested. change the declaration: to

Wow, it works! Thank you <3

Goes to show, the stupid mistakes are the hardest to catch .

Well certainly now it's calling the function, even doing the dirty work (the key goes through, is buffed, and gets printed, though it's actually the wrong key O.O). However, it GPFs after that (which I'm working on fixing -- I'm hoping that making it dynamic will help .

check the return address . (you may need to use a asm stub for your interrupt handlers).

Hmm... What would such a stub contain? I thought I had about everything I needed included in the current one. Do I also need to cli/sti or something?

I'd like to remind you of Brendan's suggestion to get the faulting EIP and error code and look them up in your sources, as well as using Bochs' debugger to isolate the exact cause.

Hm. I'm not entirely sure how to do the first one, and the second one requires me to have bochs (which historically hasn't wanted to compile on this system, and most binary packages don't work on here). I could try compiling it again, but from what I understand, bochs isn't complete enough to run most oses anyway. Qemu works for me generally, but I end up grepping through endless lines of asm output to find what went wrong (not to mention, my GPF output is in the IDT, and that makes tons of calls as well, further complicating the matter). My best bet is probably to figure out what is killing it using my kernel_assert(), though that won't do much if the problem is, say, after the iret. and before when it resumes into the main code.

Are you remembering to restore all registers? If that isn't causing the problem, it may be something to do with the way d handles functions.

In my (c) kernel I need to do the following: This would normally be done when you return from the function, but as you are effectively bypassing the normall method of returning (by calling an 'iret') , you need to put this kind of thing in manually. A simpler method would be to use an asm stub.

Hope this helps,
OScoder

hakware wrote:Hm. I'm not entirely sure how to do the first one, and the second one requires me to have bochs (which historically hasn't wanted to compile on this system, and most binary packages don't work on here).

What kind of development host do you use if binaries don't work and Bochs doesn't compile?