At 8:45 AM -0500 12/4/04, Tim Kelly wrote:

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

Ugh. In reviewing all of the discussion I realized I came to the wrong
conclusion regarding the above and how virqs are allocated. Shared hardware
irqs will have the same virq. However, I mistakenly thought that there
could be a conflict with different hwirqs sharing the same virq, when in
fact they will not be given the same virq. I had believed that they would
when I saw that mace's irq 2 was not getting to some reporting code I had
put indicate the virq mapping so that I could determine what device was
having its pending interrupt locking in MP. The actual fact is that mace's
irq 2 is not established by default. My mistake, and I apologize for the
noise.

tim