Page 1 of 1
Impossible Problem (about interrupt)
Posted: Sun Feb 28, 2010 8:42 am
by shindow
hi,everybody,what i want to do is make interrput not reentrant.
the IRQ0:
Code: Select all
sti
push
mov [var],esp
call PIT_Handler
mov esp,[var]
pop
cli
ret
Actually,it is not all,but it can express what i think
Code: Select all
void PIT_Handler()
{
// Update_Time();
test();
// Scheduler();
Send_EOI(IRQ0); //发送EOI
}
we leave Update_Time and Scheduler,let's see the test
Code: Select all
void test()
{
int i=1;
while(i--){}
}
and here is the keyboard interrupt
Code: Select all
sti
push
mov [var],esp
call KeyBoard_Handler
mov esp,[var]
pop
cli
ret
Now it is okay to press any key,it will display a "**" .But if you make the i=1000 in test ,Some thing goes wrong,what i have debug is proved that in the process of interrupt IRQ0 it is interrupted by the keyboard,I don't know why i have set the sti,it should not be interruted,but it did,and if i=1,it will not.
Is the anything related about the time of the procssing of interrupt.
Thank you inadvance
Re: Impossible Problem (about interrupt)
Posted: Sun Feb 28, 2010 8:51 am
by shindow
Is possible that if you excute sti,and you stay for a long time in the IRQ0,then IF bit will be set???
Re: Impossible Problem (about interrupt)
Posted: Sun Feb 28, 2010 9:00 am
by jrepan
I think you have sti and cli swapped. sti enables interrupts, cli disables them.
Re: Impossible Problem (about interrupt)
Posted: Sun Feb 28, 2010 9:38 am
by shindow
no ,you are wrong i have checked it
Re: Impossible Problem (about interrupt)
Posted: Sun Feb 28, 2010 9:52 am
by Gigasoft
You obviously didn't check it hard enough.
Re: Impossible Problem (about interrupt)
Posted: Sun Feb 28, 2010 9:55 am
by gravaera
Hi,
cli - CLear Interrupt flag; sti - SeT Interrupt flag.
Also, you have 'push' statement which specifies no operand in the first snippet. That is supposed to generate an assembler error, and you generally shouldn't be fiddling with the interrupt flag unless you save the state first, since usermode may have cleared irqs before calling the kernel, and may be expecting to be returned to with them disabled.
Apart from that, I'm afraid I'm hard pressed to understand your question
--gravaera
Re: Impossible Problem (about interrupt)
Posted: Sun Feb 28, 2010 11:24 am
by -m32
shindow wrote:no ,you are wrong i have checked it
Wow. Just, wow. Learn to program before even attempting to think about writing an OS!
Re: Impossible Problem (about interrupt)
Posted: Sun Feb 28, 2010 1:06 pm
by Gigasoft
gravaera wrote:and you generally shouldn't be fiddling with the interrupt flag unless you save the state first, since usermode may have cleared irqs before calling the kernel, and may be expecting to be returned to with them disabled.
On interrupts, the EFlags register is saved, so IRQs will be automatically restored when executing the iret. Besides, usually user mode code is run with IOPL=0 and can't change the I flag.
Re: Impossible Problem (about interrupt)
Posted: Sun Feb 28, 2010 1:34 pm
by gravaera
Ah, good point. Thanks
--All the best,
gravaera
Re: Impossible Problem (about interrupt)
Posted: Sun Feb 28, 2010 7:14 pm
by shindow
Also, you have 'push' statement which specifies no operand in the first snippet. That is supposed to generate an assembler error,
I just want to make the code short and easy,push is
Code: Select all
pushad
push gs
push fs
push es
push cs
For short ,my question is that(although i have solved it by adding some code) if you come to the interrupt handler and execute sti
,and if you stay here for a short time it is okay ,but if you stay here for a long time ,the keyboard handler could be called,it is actually in the clock handler the IF bit is cleared.But why is that
Re: Impossible Problem (about interrupt)
Posted: Sun Feb 28, 2010 11:10 pm
by Brendan
Hi,
shindow wrote:For short ,my question is that(although i have solved it by adding some code) if you come to the interrupt handler and execute sti
,and if you stay here for a short time it is okay ,but if you stay here for a long time ,the keyboard handler could be called,it is actually in the clock handler the IF bit is cleared.But why is that
STI = Set the interrupt enable flag = enable interrupts
CLI = Clear the interrupt enable flag = disable interrupts
Also, for interrupts there's 2 types of gates you can use in the IDT. The first type is a "trap gate" which leaves IRQs alone. The second type is an "interrupt gate" which automatically disables interrupts for you. If your interrupt handler needs interrupts disabled then it needs to use an "interrupt gate", and if you use a "trap gate" then you can get an IRQ before you get a chance to disable interrupts (with CLI).
Basically, you shouldn't need CLI or STI in an interrupt handler, except for one (rare/tricky) case that uses an "interrupt gate" and goes like this:
Code: Select all
interrupt_handler:
;Code that must be run with interrupts disabled (interrupts automatically disabled by CPU)
STI ;Enable interrupts
;Code that can be run with interrupts enabled
Cheers,
Brendan
Re: Impossible Problem (about interrupt)
Posted: Mon Mar 01, 2010 12:26 am
by shindow
Thank you,Brendan. That's the important point. and thank you everyone for my problem.I am totally wrong.
But i don't get this sentence very well,
Brendan wrote:and if you use a "trap gate" then you can get an IRQ before you get a chance to disable interrupts (with CLI).
"trap gate" ,do you mean the excetption 0-31 and "interrupt gate" is IRQ0-IRQ15 and your own interrupts
Re: Impossible Problem (about interrupt)
Posted: Mon Mar 01, 2010 2:15 am
by Love4Boobies
It means that should your handler need not be interrupted, you should use an interrupt gate. There is a chance that right after you trap but before you execute "CLI" an IRQ will occur; this is not possible with an interrupt gate because interrupts are masked atomically by the interrupt gate.
Re: Impossible Problem (about interrupt)
Posted: Mon Mar 01, 2010 6:58 am
by shindow
thank you , i get it.I am new here ,should i do something to make this topic is done.