Re: kernel stack overflow due to deep interrupt nesting

Rafal Boni <[email protected]> figured out the hard fact in NetBSD/sgimips;

 > I finally tracked down the problem to a kernel stack overflow due to
 > too deep interrupt nesting... Here's a backtrace (the panic is a
 > check I added to make tracking this down a bit easier):

With proper assignment and implementation of "spl-scheme," there should be
a limited number of nested interrupts happen on any moment.  Since the
way for computer hardware designer to offer "hardware interrupt mask" may
vary while binding between MIPS processor (hard) interrupt IM bits and real
devices are left arbitrary, we can't have a single general solution in MIPS
MI space.  That's the reason why cpu_intr() was introduced to make itself
neutral to specific hardware design.

I, personally, believe in the simpliest "binding" is to have a single hardware
IM bit for every devices while keeping them organized with a pair of
bit-arrays; one to tell interrupt condition pending and another to
disable/enable processor's IM bit turned on or not.  The notion of
"interrupt level" can be realized according to which category of devices
are attached.
Here is the example of (rather) inferior/awkward bindings;
- bind devices to any of IM bits in ad-hoc way.
Can work in the case of small number of devices and no standardized
drop-in "I/O" cards considered optional.
- have hardware interrupt masks rather complicated to handle
Vr41xx delivers a variey of interrupts in the way which mandates to
handle two level interrupt dispatcher and linked list travasal.  The
mechanism looks very CISCy, IMHO, and introduce overheads
even on the simplest form to handle interrupts.  Though I can't
comment further on its "16bit device" approach, the interrupt
scheme is questionable at best.

Toru Nishimura/ALKYL Technology