Keystrikes don't generate IRQ1

[yucarp]

I am currently trying to write some drivers for my OS and I wanted to write the PS/2 driver first. I sent the commands to PIC, unmasked the first (not the zeroth) bit and initialized the PS/2 driver. Although I followed the information on the wiki on initializing the driver the keyboard doesn't generate any interrupts on key strike. I am sure that interrupts work correctly. I have been examining the PIC and PS/2 code but I couldn't find anything wrong. I am also sure that I am acknowledging IRQs. The code can be found here: https://github.com/yucarp/ric I am sorry if I am being a nuisance, Thanks for any help

[VSlezak]

It seems that you are immediately returning from your kernel_startpoint(). However, that mean, that you will immediately fall into hlt instruction in boot.s:

Code: Select all

call kernel_startpoint

lop: hlt
jmp lop

which will halt any incoming interrupts.

[nullplan]

which will halt any incoming interrupts.

Not quite sure how you get to that baffling statement. The loop shown is a normal idle loop. Provided the interrupt flag is set on entry, it will simply wait for interrupts infinitely, because that is what "hlt" does. And it appears that interrupts are indeed enabled.

So I would check from the top: Is the interrupt flag set when the hlt loop is entered? Is the IDT indeed loaded correctly? Is the interrupt handler connected correctly? Are interrupts enabled in the keyboard controller? Is keyboard scanning enabled?

Those are the starting points I would work on.

[VSlezak]

Uh oh, it seems that I blacked out on that It reminded me of situation when this loop is written with cli, which is designed for situation when kernel error occurs, and then interrupts are blocked. But now I see that cli simply is not there. Sorry.

[yucarp]

Well, all of this happened because I forgot to enable the keyboard by sending a command And I made a mistake on my interrupt handler, I accidentally wrote (32 - int_no) instead (int_no - 32) in a case where int_no is bigger than 32. But there is still a problem. The first keystroke generates both IRQ0 and IRQ1. After that it doesn't generate any interrupts.

[yucarp]

Oh god I am really stupid... I was sending the acknowledgement command to PIC0_DATA (0x21) instead of PIC0_COMMAND (0x20)... At least I initialized the PIT too while trying to figure out the problem, now the only thing left is matching scancodes...