Thanks for your help in trying to figure out that Vr41xx interrupt problem
that we were experiencing.
In case you haven't been following the linuxce-devel list, I wanted to let
you know that Mike Klar found and fixed a problem in our Vr41xx
int-handler.S where the timer interrupt which has both a cpu and cascaded
(ICU) appearance (which we don't use) wasn't being handled properly. The
problem was (I think) that occasionally the cascaded appearance was getting
serviced, causing delayed serial interrupt handling (or worse - I'm not
entirely clear about precisely what was actually going on). Mike
hard-masked out the cascaded appeareance (since we request_irq the cpu
appeareance and don't need the cascaded appearance) for that irq and at
least a couple of others and interrupts seem to be working fine now.
----- Original Message -----
From: Ralf Baechle <email@example.com>
To: Bradley D. LaRonde <firstname.lastname@example.org>
Cc: <email@example.com>; <firstname.lastname@example.org>
Sent: Thursday, September 30, 1999 9:27 AM
Subject: Re: Interrupts during interrupts, masking and unmasking
> On Wed, Sep 29, 1999 at 06:58:46PM -0400, Bradley D. LaRonde wrote:
> > OK, but I thought it would be more than a few bytes since doesn't the
> > 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
> > overwhelming.
> No, but you can add debug code to your interrupt handler which checks that
> if the interrupted code was in kernel mode and the current stackpointer is
> kernelsp - PT_SIZE, then something is smelly. Ok rather improbable case
> if you're using the standard macros from <asm/stackframe.h> like the
> other systems, they should take care of things.