> > 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.

One thing that causes 'unexpected interrupts' is when the device drives
clears the pending interrupt request (by writing to the target hardware
register) just before exiting the ISR.

The write gets delayed (in all sorts of places, the first is a fifo
before the data cache) - so the ISR exits before the hardware has
dropped its IRQ line.

The system then takes another interrupt - which the device driver
isn't expecting (ie no IRQ bits are set in the hw register).
Falling off the list of isrs causes the error message.

The only architecture independant way of ensuring the write actually
happens is to read back the same location.  Hardware interlocks ensure
the read bus cycle follows the write cycle - all way down to the
physical chip on the IO card.

(I suspect that on the sparc cpu the kernel interrupt code could check
that the IRQ line is still active before outputting the 'unhandled
interrupt' message.  Last time I looked at sparc low level ISR code
it was all done in software....)

    David