Hi Michael,

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

>> That shouldn't affect establishing the interrupt, as it just keeps two
>>devices with different
>> interrupt types from sharing the same virq.
>In my case it led to all devices getting their own virqs.
>
>> 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

>Something totally different - IRQ sharing doesn't seem to work very well -
>as you may have seen on my >dmesg there's a Yamaha audio card and all the
>USB stuff, all on IRQ25 from the PCI bridge. Both work >pretty well, but
>playing audio and then moving the USB mouse leads to a deadlock after a
>while - >apparently no interrupts from this line get processed anymore.
>Audio loops and USB devices are >unresponsive. The rest of the kernel was
>still working so I just rebooted.

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?

>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 :-)

tim