Yet another question about keyboard's irq

[CyberP1708]

My problem is about a simple ps/2 keyboard (just like what you have in the FAQ)

Here is the code which remaps the pic :

Code: Select all

outb(0x20, 0x11);            // ICW1
outb(0xA0, 0x11);

outb(0x21, pic_irq_first);         // ICW2
outb(0xA1, pic_irq_first + 8);

outb(0x21, 0x4);            // ICW3
outb(0xA1, 0x2);

outb(0x21, 0x1);            // ICW4
outb(0xA1, 0x1);

outb(0x21, 0x0);            // OCW1
outb(0xA1, 0x0);

And here is the one that initialise the keyboard interruption :

Code: Select all

cpu_idt_modify(pic_irq_first + 1, keyboard_ps2_handle_int, 8, 0x8E00);

The problem is that it doesn't work (nothing happens, the function "keyboard_ps2_handle_int" isn't called)

If I remove the "+1" I get this on the screen when I write "test" for example :
[tt]ttttttttttttttteeeeeeeeeeeeeeeesssssssssssssstttttttttt[/tt]
which is normal because instead of getting an IRQ every time a key is pressed or released (IRQ1), I get one every 1.42 ms or something like that (IRQ0)
This proves that the interruption flag is set and that the code to get the key is working
So my problem is that no IRQ1 is generated
What do you suggest ? :-\

[Pype.Clicker]

This proves that the interruption flag is set and that the code to get the key is working.
So my problem is that no IRQ1 is generated
What do you suggest ? :-\

Well, either the keyboard is disabled (i think there are commands to do that documented in PS2 keyboard/mouse tutorials) or the bit 1 in the master IRQ mask is set.

Since there's no reason for the keyboard to have been disabled (unless you did it), i'd suggest you print the content of I/O port 0x21 and see which interrupts are enabled (bit cleared) and which are masked (bit set).

[octavio]

on some keyboard controllers a irq is generated when there is
data from the keyboard(irq1) or aux device (irq12) but not
when a status byte (due to some error) from the keyboard
controller is placed in port 60h ,in this case the controller is bloqued until this byte is read.
Same problem if you don?t read the data from the mouse
with irq12.

[CyberP1708]

I tried to read the mask and it told me "0x0" (what was expected)
I also tried to disable every other function using the same ports than the keyboard (like flashing leds for example) but it was still not working ???

so I rewrote my keyboard driver and now it works...
I will never know why it wasn't working but it doesn't matter anymore as it is working perfectly now
thank you anyway

[CyberP1708]

Well I think I have found the bug, and that leads to another problem
If I mask the IRQ 0 on the master PIC (OCW1 is 0x1) it is working
But if I don't mask it (OWC1 is 0x0) it doesn't work

I have disabled everything that was using IRQ0 (I think)

[CyberP1708]

I found the problem and it is very stupid in fact
When I create my IDT, every interruption are linked to a simple function (in assembly) which was:

Code: Select all

cpu_80386_idt_default_receiver:
   push ax
   mov al, 0x20

   out 0x20, al

   out 0xA0, al
   pop ax

   iretd

Of course the "iretd" opcode doesn't exist (it is only iret) and the cpu was executing what was following in the memory (certainly in the data section), which leads to an "undefined behavior"

[Brendan]

Hi,

Of course the "iretd" opcode doesn't exist (it is only iret) and the cpu was executing what was following in the memory (certainly in the data section), which leads to an "undefined behavior"

Hmm - which assembler? For NASM, there's "IRET", "IRETW" and "IRETD".

"IRET" does either a 16-bit IRET (if "BITS 16" is being used) or a 32 bit IRET (if "BITS 32" is being used). "IRETW" always does a 16 bit IRET (even if "BITS 32" is being used), and "IRETD" always does a 32 bit IRET (even if "BITS 16" is being used).

Also, I strongly recommend using the "-w+orphan-labels" comand line option so that NASM generates an error if a label is defined without a trailing colon. For example, consider something like:

Code: Select all

    pushflgs
    clri
    loadsb
    storsb
    popflgs

    ireet

Normally NASM will silently assemble this thinking that they are all labels. With the "-w+orphan-labels" option it'd stop at the first messed up instruction and tell you there's a label without a colon - it can prevent many hard to notice problems.

For fun, try to find this bug:

Code: Select all

    MOV EAX,0x12345678
    ST0SD

Now bury this bug in 100 lines of source code.

If your not using NASM there should still be an option like "-w+orphan-labels"...


Cheers,

Brendan

[CyberP1708]

Thank you, I didn't know this option