Page 1 of 1
Loops affecting interrupts?
Posted: Wed Jun 19, 2013 4:49 am
by 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.
Re: Loops affecting interrupts?
Posted: Wed Jun 19, 2013 10:19 am
by Mikemk
CocaCola wrote: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.
Re: Loops affecting interrupts?
Posted: Wed Jun 19, 2013 10:51 am
by CocaCola
m12 wrote: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.
Re: Loops affecting interrupts?
Posted: Wed Jun 19, 2013 11:17 am
by 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.
Re: Loops affecting interrupts?
Posted: Wed Jun 19, 2013 11:54 am
by bluemoon
CocaCola wrote: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.
Re: Loops affecting interrupts?
Posted: Wed Jun 19, 2013 9:49 pm
by 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).
Re: Loops affecting interrupts?
Posted: Thu Jun 20, 2013 12:05 am
by CocaCola
halofreak1990 wrote: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.
Nessphoro wrote: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
Re: Loops affecting interrupts?
Posted: Thu Jun 20, 2013 7:59 am
by JAAman
CocaCola wrote:
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:
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)
Re: Loops affecting interrupts?
Posted: Fri Jun 21, 2013 1:00 pm
by 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
Re: Loops affecting interrupts?
Posted: Fri Jun 21, 2013 2:53 pm
by 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.