Subject: Re: results of the IRC debug patch
To: Tim Kelly <hockey@dialectronics.com>
From: Michael <macallan18@earthlink.net>
List: port-macppc
Date: 12/04/2004 09:01:28
Hello,

> >I'd like to figure out if some code was
> >removed that differentiated between the interrupt types when determining
> >the irq handler to call. When esp and mace share the same virq 2, I don't
> >see how mace's handlers get called if the virq to be processed is 2.
> 
> No code has been removed. Instead of working backwards I just looked at the
> original commit. I just don't see how this code:
> 
>   irq = 31 - cntlzw(hwpend);
>   is = &intrsources[irq];
>   if (!have_openpic)
>       gc_enable_irq(is->is_hwirq); ci->ci_ipending &= ~(1 << irq);
>   splraise(is->is_mask);
>   mtmsr(emsr);
>   KERNEL_LOCK(LK_CANRECURSE|LK_EXCLUSIVE);
>   ih = is->is_hand;
>   while (ih) {
>        (*ih->ih_fun)(ih->ih_arg);
>        ih = ih->ih_next;
>   }
> 
> differentiates between mace on virq 2 and esp on virq 2. Of course, with
> irq 2 not established by if_mc.c, this conflict never occurs, and it is
> conceivable that this conflict doesn't occur under any other circumstances.

So that's why it's commented out in if_mc.c

But... there seems to be no support at all for different virqs on the same hardware IRQ - everything seems to assume that a virq corresponds to exactly one hardware IRQ. Things like 
	irq = virq[realirq];
won't work if you use different virqs for one HW IRQ - virq[n] will only contain whatever IRQ was established last.
Slowly I see why mc didn't establish the IRQ - looks like a veritable can of worms.

have fun
Michael