Keyboard interrupt

[Pype.Clicker]

as the comment says, current_mask=0xffff prevents all the IRQ to come to your processor. current_mask=0xfffe allows only the clock and current_mask=0xfffd allows only the keyboard to be received.

You may think whatever you want, but as long as there may be a clock IRQ in the way, we cannot tell whether the error is caused by something wrong in the way you setup the keyboard or if it's due to a clock request that goes in the void because it has no handlers ...

Also, i don't know exactly what is hidden behind enable_irq(...), but as you can read in the FAQ, you *cannot* put a C function's address in the IDT. You need an ASM stub that will save/restore registers for you ...

[ich_will]

This is the hole source code of the idt/pic functions

[attachment deleted by admin]

[attachment deleted by admin]

[Solar]

Did you actually *read* Pype's advice and link?

You cannot use your C function default_handler() as interrupt handler without surrounding ASM stub!

Read the FAQ about why not.

[Candy]

Did you actually *read* Pype's advice and link?

You cannot use your C function default_handler() as interrupt handler without surrounding ASM stub!

Read the FAQ about why not.

Sorry to kick the OSFAQ, but it IS possible, just very compiler dependant. You CAN use a C routine with only a C-ish stub, or if it doesn't use any local vars, directly. Still, even I don't advise it.

Code: Select all

void int_handler() {
  asm ("pushad");
  do_something_or_call_a_function();
  asm ("popad; leave; iret");
}

This code worked for me (actually) in GCC 3.2.2 and 3.3. I cannot guarantee it works, disassemble your code to be sure.

[Solar (not logged in)]

Well, yes, it *is* possible with a bit of tweaking, which means you have to be aware that a plain function doesn't work - which ich_will obviously is not...

[Pype.Clicker]

@candy:
indeed, the "leave" instruction (or mov esp, ebp; pop ebp) will somehow works. However, the 'popad' may not work if GCC decided for some obscure reason to postpone the "add esp,X" that follows the call ...

Imho, playing that way is very risky, especially as soon as your interrupt function plays with local variables and things like that. Safe Hex requires you to wrap an ASM stub around your GCC-generated interrupt handler ... keep safe ...

[Candy]

However, the 'popad' may not work if GCC decided for some obscure reason to postpone the "add esp,X" that follows the call ...

which doesn't change within the same version of GCC now does it?

Imho, playing that way is very risky, especially as soon as your interrupt function plays with local variables and things like that. Safe Hex requires you to wrap an ASM stub around your GCC-generated interrupt handler ... keep safe ...

I said it was a bad idea to do it, but it was possible, even though you said it was not. I'm for the 100% truth, not the 99% truth-but-a-lot-clearer.

If it's possible, don't say it isn't. Say it's really hard and really unstable.

Still, for a first try of interrupt handling, you might not give a ****.

[Solar]

That's why we were referring to the FAQ, which details it quite nicely that "you can't do it" is only 99% of the truth. That's what a FAQ is for - so you can give a short answer and a link instead of having to roll out the whole story all over again.

No offense intended. It's just, fighting for a better signal / noise ratio for > 10 years can be rather exhausting...

[ich_will]

in my opinion the problem is not the C-Function, because it works with bochs and on my other PC but not on my Duron.

[Pype.Clicker]

so i'm glad to know your opinion ... But i still haven't seen your possibly faulty keyboard handler. I think you're picking up things with the wrong end.

Obviously, your DURON is not your default test machine, so i guess it's been a long time since you didn't test your code on it, right ? try to simplify what you do (disabling clock was one example), or to make your code cleaner (using ASM wrapper for interrupts)...

Only once you'll have found what was wrong on the Duron can you focus on "how the hell could it even have worked in BOCHS" ...

There are good-practice rules that help us writing reliable OS code and we try to show you those rules.

I also see that your 'default handler' does not send EOI ... this certainly doesn't help.

[ich_will]

OK I through away the old code and write new.
just it works on my Duron (but I don't realy know where the bug was) like on the other PCs. But yet there is another problem: if I press a key the keyboard handler is called once and a message is out (from the default_handler).

Code: Select all

;------------------- idt_handler.asm -----------------
[extern _putstr]
[extern _send_eoi_slave]

[global _default_handler]
//... the cpu0 to cpu16 functions
[global _keyboard]

msg_def db 10,"An unhandled interrupt has occured...",10,0
//... and all other msgs

putstr:
  push eax
  call _putstr
  pop eax
  ret

_default_handler:
  pushad
  cli
  mov eax, msg_def
  call putstr
  sti
  call _send_eoi_slave
  popad
  iret

_cpu0:
  cli
  mov eax, msg0
  call putstr
  hlt
//... and the cpu1 to cpu16 functions (like the cpu0)

_keyboard:
  cli
  pushad
  extern _keyboard_handler
  call _keyboard_handler
  popad
  sti
  iret

;------------------------- keyboard.c ---------------------
void keyboard(); // in the idt_handler.asm 

void keyboard_handler()
{
  putint(inportb(0x60));   //retrieve scan code
  putc(' ');
  send_eoi_master();
}

void init_keyboard()
{
  putstr("Initialize the Keyboard............");
  
  enable_irq(1,keyboard);
  
  putstr("DONE\n");
}

[Pype.Clicker]

i think a tutorial about interrupts could be useful for you ... When your interrupt handler is done, you have to tell the Programmable Interrupt Controller that you're done and that it can now send you more interrupt requests.
This can be done by sending '0x20' on the PIC's main port, thus

Code: Select all

    mov al, 0x20
    out 0x20,al

when your interrupt is bound to the master pic (which is the case for IRQ0-7) and

Code: Select all

    mov al,0x20
    out 0xa0,al
    out 0x20,al

if your interrupt is bound to the slave PIC.

Moreover, it's useless (and even sometime hazardous) to CLI/STI within the interrupt handler: The CPU will automagically clear the interrupt flag before executing the first instruction of your handler and IRET will restore the previous IF value...

[Candy]

when using AEOI mode it shouldn't be necessary, right?

[distantvoices]

To be nitpicking is sometimes nice: it is AIEOU, and this is some boast of the early Habsburger regents of Austria *gg*

[Candy]

To be nitpicking is sometimes nice: it is AIEOU, and this is some boast of the early Habsburger regents of Austria *gg*

I was being serious

AEOI == Automatic End Of Interrupt mode...

AIEOU == Aie Owe You?