[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

    Get IRQ N
    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
    ***** FILE SYSTEM MODIFIED *****
    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.021 / U:4.784 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site