[spif]
>> When it is attached, it is being given interrupt level 13.  When
>> it tries to attach itself with bus_intr_establish, though, it
>> turns out something else has already pinched 13 for a fast vector
>> interrupt.  ("panic: intr_establish: level 13 interrupt tied to fast
>> vector")
>> 
>> How do I sort this out?  I've no idea what it is that's tied to 13,
>> so I don't know how to tell it to use something else, and I don;t
>> know how to tell the spif to try something else either!
> 
> can you show us the entire boot message?  that should indicate who
> had ipl 13.  though, it seems to be that all the serial devices in
> a sparc should share the same ipl (ie, zs is 12) but that doesn't
> seem to be feasible with the fast interrupt handler for zs...

I don't have the boot message to hand unfortunately, but it turns
out that the audio driver is nicking 13.

Jason (thanks!!) suggested I try using AUDIO_C_DRIVER.  Unfortunately,
it seems that this hasn't been maintained.  I fixed the obvious bugs in
the C audio driver code, and did manage to get round the fast interrupt
conflict...  Unfortunately, I've also got myself a system that wedges
horribly when I try & use the serial device.

Now I don't know whether it's the spif driver or the audio driver
causing the wedge...  Still, I'll have another bash tonight with the
audio driver disabled totally and see where I get!


Out of interest, what is that 'hands out' the interrupt levels to the
devices?  Is it all decided by the PROM before boot, or does the NetBSD
kernel allocate them??  Sun device programming is a bit new to me ;-)

Cheers,
Tim.

-- 
Tim Walls