Hello,

> >> Which patch, the one with non overlapping virqs?
> >I think so:
> >#if 0
> >	if (virq[irq])
> >		return virq[irq];
> >#endif
> >this one caused the problem.
> 
> Yep. That should be removed. I have not fully grasped how the virq sharing
> is done.
I'm not so sure it's done at all...

> >> Did you get the mc0 error messages before you enabled the irq 2?
> >No, only the usual co carrier blah, which is understandable - there is no
> >carrier :)
> 
> 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 :)

> Not that I'm an expert on the interrupt masking (I only said you "asked me
> to explain," I didn't say I managed to actually do it correctly), but is it
> possible that the devices are registering at different IPL levels? How
> would this impact sharing a virq?
No idea, I thought you already dug a little deeper. So I'll have to look at it too...
The Yamaha uses IPL_AUDIO(2), the USB stuff uses IPL_USB which is IPL_BIO(6) in disguise. 

> >Btw. heavy traffic on a USB disk connected to a different controller (
> >function 2 vs. function 0 ) didn't >seem to collide with the USB mouse at
> >all, so in this case sharing seems to work well.
> >
> >Any idea?
> 
> Probably too many bad ones and no good ones :-)
Hmm, each one alone works fine. So, I didn't really look at the code (yet), maybe you can answer this - if one device behind the bridge fires an IRQ - will every driver which established something on the same IRQ get called? Or is there some dispatching done through the bridge? If everyone's called the I guess I should have a look at the yds driver...

have fun
Michael