Unknown lockup with Keyboard LEDs?

[stonedzealot]

I wrote my keyboard driver without a hitch in C. No problem there. I added shifting/caps locking support too, but then realized that I needed to get those damn little LEDs to work.

I did it in ASM to make the interfacing a little easier and faster, and it looked a little something like this:

Code: Select all

boardLEDS:
xor cl, cl
mov cl, [caps_state]
add cl, [num_state]
add cl, [scroll_state]
mov [final_state], cl

kwait:                                ;Wait for clear
in al, 0x64
test al, 0x02
jnz kwait

mov dx, 0x60                    ;Send function code
mov al, 0xED
out dx, al

kack:                                 ;Wait for acknowledge
in al, 0x60
test al, 0x80
jne kack

kwait2:                              ;Wait for clear
in al, 0x64
test al, 0x02
jnz kwait2

mov al, [final_state]          ;Set LEDs
out 60h, al

kack2:                              ;Wait for acknowledge
in al, 0x60
test al, 0x80
jne kack2
ret                                    ;Return.

This code is called everytime one of the pertinent keys is pressed (Caps, Num or Scroll locks). The driver is called from the C master interrupt controller (one function for all interrupts) which in turn calls the driver. Without the LED code, the driver works like a charm.

With the LED code in place, it runs through the code, set's any appropriate LEDs (e.g. does it's job), returns to the driver, returns to the master interrupt controller and then halts. No errors our faults or anything, but you can no longer input anything with the keyboard (note: I did free the interrupt after the driver code was executed), or do anything else in the os. Also keep in mind that this is being called from a C function that should take carve of all pushs and pops to the stack that it makes.

In brief:
Code compiles, links and executes
One key is pressed, driver does it's job
OS locks (no more input).

[Ozguxxx]

do you acknowledge interrupt controller while handling interrupt?

[Candy]

Did you listen for the ACK the keyboard might send?

[stonedzealot]

Candy: Yep, I'm listening and waiting for the ACK (shown in the above code in kack and kack2)

Oz: Sorry, I don't know what that means... as far as I know, all I have to do with the interrupt controller is release it (outportb(0x20, 0x20)) after I've finished the driver code, and I'm already doing that.

[Ozguxxx]

Well, http://my.execpc.com/~geezer/osd/kbd/index.htm gives a code snippet, I cannot remember how to program keyboard controller apart from key reading, but this Chris Giese's code does not have a kack2 loop (I think) after sending turn on leds data. This may be why your kernel halts, but I am just speculating, I am not sure. I hope this helps, good luck.

[stonedzealot]

Thanks, but I misspoke before. I'm not sure if the kernel actually halts or not, I think it's just that the interrupt won't fire again, because the code actually returns from the LED code and the driver code.

Just to make sure, I tried Giese's code but no joy. The real question is how the addition of this code could take a working interrupt and make it not fire again.

[stonedzealot]

Figured it out! You were right...sorta. It was a timing issue, but it was that it had too little time, not too much. I fixed the problem by adding dead space in (a long loop). The function was being called too fast for the computer to handle (I guess?) so it locked itself. The problem stemmed from the fact that I was updating the keyboard LEDs on both the make and break codes for Caps, Num, and Scroll Locks.

D'Oh. Thanks alot for you're help!