Hello,

> >> Gees, enabling irq 2 now leads to collision errors when it's not even
> >> plugged into a network :-P
> >Well, if mesh interrupts and mc doesn't know it's sharing the IRQ :)
> 
> I would think that would occur if there is virq sharing, which is what I
> had stopped. You were getting it without the sharing.
Well, the mc probably doesn't know the difference anyway - complaining about collisions when there's no connection isn't such a rare mis-feature.

> My thought, naive as it might be, is that if a virq raises the IPL to a
> level higher than other IPLs of devices using the same virq, and one of
> those virqs then attempts to get processing time, it gets deferred. In the
> case you describe, audio would block mouse.
This would match the symptoms.

> As each ih_fun was established for each driver, as long as there are one or
> more handlers, they get called. I don't know if sharing virqs adds handlers
> to the existing ih structure or if they get put in their own. It is quite
> relevant, though.
Hmm, I've been looking for the PCI-PCI bridge and the DEC21052 specifications to figure out how interrupt routing is supposed to work, couldn't find anything yet - both cards get their interrupts assigned through some code copied from 1.6 which uses the parent's interrupt-map for devices without proper interrupt property, which leads to all devices behind the bridge sharing the same IRQ, maybe I need to do a bit more to properly set up IRQ routing, the current approach looks a bit too simplicistic right now, the IRQs shouldn't influence each other like that.

have fun
Michael