Subject: MIPS Interrupts.

From: "Kapoor, Pankaj" <[email-masked]>
Date: Tue, 25 Nov 2003 16:52:20 -0500

All,

While studying the implementation of tasklets and softirq processing I came 
across certain issues which I have outlined below. 

The function mipsIRQ in the file mipsIRQ.s is the registered interrupt 
handler for all general purpose interrupts. 

The first thing that the function does is that it saves all registers. It 
then checks the CAUSE register to check the source of the interrupt.
Currently 
all we are interested in is INT5 (Timer) and INT0 (i.e. all other devices) 

Consider a timer interrupt which would cause the code to jump to 0x8000:0180

and cause all the registers to be saved (SAVE_ALL). It would then jump to
the 
mips_timer_interrupt function in the file time.c 

The function services the timer interrupt. At the end of the function there 
is an irq_exit and a check to see if there are any SOFT IRQ pending. 
If there are any the function jumps to the do_softirq function defined in 
the softirq.c. The function gets the softirq pending list, enables
interrupts 
and cycles through all pending soft irq's calling the appropriate handlers. 

Remember that the interrupts are enabled while executing the various bottom 
half handlers. 

Now there are 2 cases that can happen 

1. Since we have not exited the ISR and the exception level has still not 
   been restored there can be no more interrupts that are generated in the 
   system. In such a case does that mean that the all bottom half handlers 
   pending execution will run with interrupts disabled. 
   NOTE: This does not seem likely because the local_irq_enable routine
calls 
   _sti which clears the exception level in the status register and also 
   sets the IE bit. 

2. If we have large number of tasklets or if the bottom half handlers take
time 
   to execute, then we could get another timer interrupt or other device 
   interrupts causing context saves which would cause the stack to grow and 
   CRASH the system. 
  
Context is restored only when the code returns from do_softirq and uses the 
ret_from_irq. 

Is there anything that I am missing in this whole picture ? 

Thanks.
- Pankaj

---

From: Jun Sun <[email-masked]>
Date: Tue, 25 Nov 2003 15:06:02 -0800

>    _sti which clears the exception level in the status register and also 

Refer to your own note.  It is more correct.  :)
 
> Context is restored only when the code returns from do_softirq and uses the 

The nested interrupt call, do_IRQ(), may still try to call do_softirq() but
that it will return immediately as it discovers another instance of do_softirq()
is running.  No further nesting occurs as a result. 

Jun

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 26 Nov 2003 00:09:46 +0100

On Tue, Nov 25, 2003 at 04:52:20PM -0500, Kapoor, Pankaj wrote:

>    calls _sti which clears the exception level in the status register and
>    also sets the IE bit. 
> 
>    time to execute, then we could get another timer interrupt or other
>    device interrupts causing context saves which would cause the stack to
>    grow and CRASH the system. 

Interrupts are disabled while the respective interrupt handler is running.

  Ralf

---

From: Jun Sun <[email-masked]>
Date: Tue, 25 Nov 2003 16:31:04 -0800

> Interrupts are disabled while the respective interrupt handler is running.

They are re-enabled for "bottom halves", i.e., in do_softirq().  I think
that is what the sender is worrying about.

Jun