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