Hi Michael,

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

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

I've dug some, but that doesn't mean my understanding is correct. Pavle
Cahyna has been helpful in making sure I have better understanding of the
IPL stuff.

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.

from extintr.c

pcpl = ci->ci_cpl;
...
irq = virq[realirq];
KASSERT(realirq < ICU_LEN);
r_imen = 1 << irq;
is = &intrsources[irq];
if ((pcpl & r_imen) != 0) {
   ci->ci_ipending |= r_imen;/* Masked! Mark this as pending */
   openpic_disable_irq(realirq);
} else {
 (handle it immediately)

The pcpl indicates what the current IPL level is. In the code to calculate
the interrupt masks, do both IPL_AUDIO and IPL_BIO consider the virq when
shared as above? I don't know. There's a lot of ORing that is used for the
hierarchy, but if virq 25 comes in, does raise the IPL to IPL_AUDIO or
IPL_BIO. Seems to me this could be a pertinent question, as you've already
indicated that playing audio can cause the mouse to stop responding.


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

I'm not sure.

while (ih) {
 (*ih->ih_fun)(ih->ih_arg);
 ih = ih->ih_next;
}

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.

tim