[lkml]   [1998]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Strange interrupt behaviour
On 11 Jul 1998, Andi Kleen wrote:

> (Alan Cox) writes:
> > 3. Drivers that get repeated interrupts appear to re-enter the handler
> > uncontrollably blow the stack and crash. I suspect nested interrupt
> > handling problems may be half the 8K stack issue, and could be tons
> > of our other remaining bugs.
> How about using a separate per-CPU 16K stack for interrupts, instead of
> handling them on the per-process kernel stack? Then we could probably
> switch back to 4K process kernel stacks too.

No. That just masks the problem. It is common for Linux interrupt handlers
to enable interrupts. They must _not_ be reentered. The kernel IRQ code

mask off IRQ N
ack the interrupt (reset in-service flag)
call interrupt handler
interrupt handler returns
unmask IRQ N
Interrupt return

The kernel code has to 'remember' the IRQ bit that caused the interrupt
in the first place. If the interrupt was masked OFF, (got a spurious
interrupt), it must not unmask the interrupt. The kernel handler can't
just save/restore the whole mask because the mask might have changed
by the time the driver code returns. It has to save/restore the bit
from the original mask and leave the other, possibly-changed, ones

Dick Johnson
Penguin : Linux version 2.1.108 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:43    [W:0.152 / U:3.516 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site