On Sun, Nov 25, 2001 at 14:33:36 -0400, Jared D. McNeill wrote:

> Well, I've started work on dbri* at sbus?, but if I call my dbri_init()
> function from dbri_attach_sbus(), I get a bunch of unhandled ipl 0x9
> messages (or something of the sort) on the screen soon followed by a
> 'panic: crazy interrupts'.

"crazy interrupts" is triggered when you get more then 10 stray
interrupts in 10 seconds.

stray interrupt is a hardware interrupt that none of the registered
interrupt handlers has claimed (by returning 1 from the interrupt
handler).

For obvious things, make sure you've added the handler at the correct
pil and that the handler returns 1 when it processes the interrupt.


FWIW, I have a very strange problem with com @ ebus in Krups
JavaStation.  When comstart is called with fewer than 8 bytes, I
receive an interrupt from com, but the IIR register denies any
knowledge of ever sending one (IIR_NOPEND) - thus making it a stray
interrupt (since comintr sees IIR_NOPEND and returns 0 immediately).
The work-around I came up with is to modify comstart to send the chunk
of data first and enable TX interrupts only after that.  This might be
a chip glitch, but I mention it here to give you an example of a stray
interrupt in a situation where you wouldn't expect (from reading the
source) to have one.


PS: In my case with com@ebus additional problem was that sometimes
during such a "ghost" interrupt from com the HW interrupt pending bit
was NOT set and sparc_interrupt4m would happily consider it a soft
interrupt (and soft interrupts are never considered stray) thus
sweeping the problem under the carpet.  sun4m's have separate soft
interrupt pending register, so at least in DIAGNOSTIC kernel we might
want to check for this condition and report it.

SY, Uwe
-- 
uwe@ptc.spbu.ru                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen