[Top] [All Lists]

Re: Interrupts during interrupts, masking and unmasking

To: "Ralf Baechle" <>
Subject: Re: Interrupts during interrupts, masking and unmasking
From: "Bradley D. LaRonde" <>
Date: Wed, 29 Sep 1999 18:58:46 -0400
Cc: <>, <>
References: <018f01bf0a84$1cf4cf70$> <>
----- Original Message -----
From: Ralf Baechle <>
To: Bradley D. LaRonde <>
Cc: <>; <>
Sent: Wednesday, September 29, 1999 5:49 PM
Subject: Re: Interrupts during interrupts, masking and unmasking

> On Wed, Sep 29, 1999 at 10:08:32AM -0400, Bradley D. LaRonde wrote:
> > I'm having trouble with interrupts that occur during interrupts.  I'm
> > working on the Vr41xx port.
> >
> > First, there was this problem that we would lose the timer irq click.
> > just stopped clicking.  /proc/interrupts showed no increase for timer.
> > happend when we pushed lots of data through the serial port.  Mike had
> > idea that it might be because of interrupts occurring during other
> > interrupts.
> >
> > But why did the timer irq stop clicking?  I could still use the console
> > w/keyboard on my Clio.  cat /proc/interrupts showed the other irqs
> > but not timer.  It was like the timer irq was getting masked.
> >
> > Hmmmm... I poked around and saw irq.c masking and unmasking in do_IRQ.
> > looked at i386 and couldn't find a similar operation.  So I commented
> > out to see if that would fix the mysterious lost timer problem.  It did!
> > Cool.  I figured the Vr is just finicky and doesn't like to be messed
> > with masking/unmasking so much.
> >
> > But... now a new problem. If all my interrupts are set for SA_INTERRUPT,
> > problem.  If I have one that isn't SA_INTERRUPT, problem, since that
> > do_IRQ do __sti.
> >
> > I wonder - if an interrupt occurs inside do_IRQ, what happens?  Does it
> > back to do_IRQ when it's finished?  It should, right?  But if it didn't,
> > could have left the timer masked.
> >
> > I'm also thinking "maybe there is some mips thing going on here".
> When the second interrupt is entered, make sure that it's stack pointer
> is loaded correctly.  It should the same as for the first one minus a few
> bytes for stackframe and other crappola.

OK, but I thought it would be more than a few bytes since doesn't the first
one push the cpu context onto the stack?

How can I determine the stack pointer for the first and second
(contemporary) interrupts?  100 printks per second sounds a little

> What is the source of your timer interrupt?  Is it the internal cycle
> counter?

On the Vr41xx it's called RTCLong1.  It feeds though the ICU and out to a
dedicated cpu interrupt (int1 I think).


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