> 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.
I know that it adds some complexity for nested interrupts, but the current
code already seems to do lots of work to handle nested interrupts, so the
costs probably wouldn't be that bad.
> 4. We've lost the fast irq stuff. Thats unbelievably bad and may be part
> of #1.
Unfortunately it would be _big_ task to edit all existing interrupt handlers
to include a return value (like originally planned). This would be very error
prone too. Maybe reintroducing the SA_INTERRUPT flag for fast interrupts
is the best solution for 2.1
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html