Impossible Problem (about interrupt)

[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

[shindow]

Is possible that if you excute sti,and you stay for a long time in the IRQ0,then IF bit will be set???

[jrepan]

I think you have sti and cli swapped. sti enables interrupts, cli disables them.

[shindow]

no ,you are wrong i have checked it

[Gigasoft]

You obviously didn't check it hard enough.

[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

[-m32]

no ,you are wrong i have checked it

Wow. Just, wow. Learn to program before even attempting to think about writing an OS!

[Gigasoft]

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.

[gravaera]

Ah, good point. Thanks

--All the best,
gravaera

[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

[Brendan]

Hi,

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

[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,

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

[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.

[shindow]

thank you , i get it.I am new here ,should i do something to make this topic is done.