linux-mips
[Top] [All Lists]

MIPS Interrupts.

To: linux-mips@linux-mips.org
Subject: MIPS Interrupts.
From: "Kapoor, Pankaj" <pkapoor@telogy.com>
Date: Tue, 25 Nov 2003 16:52:20 -0500
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
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 


<Prev in Thread] Current Thread [Next in Thread>