Loops affecting interrupts?

[CocaCola]

Hello.
I have set the handler for the PIT to print something on screen.
However when a loop is entered, the printing is suspended.

Consider this simplified panic() function, which seemingly prevents the PIT handler from printing to the screen.

Code: Select all

void panic(const char *message)
{
    printf("PANIC - %s!\n", message);

    while (1);
}

Also when a loop runs, the keyboard handler is suspended as well, and "remembers" the keys pressed as soon as the loop ends.

Question 1: why does this happen?
Question 2: how can I achieve an "asynchronous" effect?

Thank you.

[Mikemk]

Question 1: why does this happen?

I don't know for sure, but my theory is that cpu time is used up by the loop.

Question 2: how can I achieve an "asynchronous" effect?

Please elaborate.

[CocaCola]

Please elaborate.

For instance, if I assign the Escape key to call a reboot() function, nothing will happen for as long as the loop runs.

Rather, the reboot() function should be called as soon as Escape is pressed, regardless of whether or not the loop had ended.

[halofreak1990]

You should never loop inside an IRQ handler. Rather, loop somewhere outside it, in your main code.
In that way, you can still recieve interrupts.

Next, you'll need a basic keyboard driver to read the keyboard scan codes and convert them into more usable character codes.

Once you have that, you can check, once a keyboard interrupt occurs, which key is pressed, and, when it's the Escape key, you reboot the computer.

[bluemoon]

I have set the handler for the PIT to print something on screen.
However when a loop is entered, the printing is suspended.

It is impossible to pinpoint the cause without prior knowledge of your OS's internals, like how your scheduler works.
For the simplest case of single thread hello world kernel, an IRQ should interrupt the loop, that's how interrupt meant to do.

However, on emulator a tight loop may demand higher workload on the host and thus cause some delay on IRQ logic.

[Nessphoro]

Looks like a newbie mistake.
PIT uses IRQ0 to signal an interrupt, this is the highest priority line and will not be interrupted by lower priority lines such as the keyboard or the CMOS timer, and since you don't signal an EOI mid IRQ handler - the IRQ controller simply thinks you're still processing it. Moreover, you probably disable interrupts when you enter your IRQ handler ( CLI instruction).

[CocaCola]

You should never loop inside an IRQ handler. Rather, loop somewhere outside it, in your main code.
In that way, you can still recieve interrupts.

It is possible that this is the problem! The interrupt handler calls a function that has a loop. So indirectly I loop in the handler.

Looks like a newbie mistake.
PIT uses IRQ0 to signal an interrupt, this is the highest priority line and will not be interrupted by lower priority lines such as the keyboard or the CMOS timer, and since you don't signal an EOI mid IRQ handler - the IRQ controller simply thinks you're still processing it. Moreover, you probably disable interrupts when you enter your IRQ handler ( CLI instruction).

No, I do not disable interrupts in the handler.

Thanks for mentioning the EOI. The article below states that I should use it in all my handlers, but I'm a bit confused which are "master" handlers and which are "slave" handlers. Slave handlers are the ones associated with higher number IRQs sent to the slave PIC, yes?

http://wiki.osdev.org/I_Cant_Get_Interr ... ve_one_IRQ

[JAAman]

No, I do not disable interrupts in the handler.

actually you do (though you shouldn't have a CLI in your code) -- when an interrupt fires, one of the things the CPU does is automatically disable interrupts -- so until you either iret or STI interrupts will be disabled

as was already mentioned, the correct solution to this is to return from the interrupt (using iret) back to your main code, and loop there

actually, usually the normal way is to end your code in a loop like this:

Code: Select all

stop:
hlt
jmp stop:

then all your interrupts will be called from, and return to, this loop (the hlt instruction will also prevent problems with the CPU overheating and other potential issues)

[lkurusa]

Hi,

I guess the problem resides in the PIC. You do not send the EOI (EndOfInterrupt) command to the master PIC, so it won't send new interrupts to the CPU.

Cheers,

Levex

[CocaCola]

Thanks everyone for the replies! The issue was solved by moving the loops out of the IRQ handlers.

As for sending the EOI signals to the master and slave PICs, I'm 90% sure I'm doing it right, because everything seems to be working.