Re: [PATCH 0/7] Boot IRQ quirks and rerouting

[Maciej W. Rozycki]

On Wed, 4 Jun 2008, Thomas Gleixner wrote:

> It does matter. When the interrupt is _not_ handled then it comes back
> immediately for ever and after a while the kernel decides to disable
> the legacy int, because nobody cares about the interrupt.

 Mental shortcut, sorry -- making the interrupt be discarded through the
primary rather than the secondary, etc. I/O APIC does not change anything.  
Based on the description of the problem, the interupt will just have to be
delivered somewhere, so I see little purpose in complicating the routing
and causing additional sharing just to discard the interrupt elsewhere
anyway.  If INTx messages cannot be blocked on the way anywhere, then the 
originating I/O APIC should never get its inputs masked and the handler 
should take care of the unwanted interrupts there.  This is at least my 
opinion.

 BTW, it could be possible to mask the interrupt by fiddling with the
vector used and the TPR instead -- we have a range of low-priority vectors
which are never used for APIC interrupts, so the TPR may be hardcoded to
some non-zero value for all systems and then for the problematic chipsets
handlers may change vectors to mask or unmask APIC interrupts.  This would
have to be verified on actual hardware and be conditional as it is likely
to cause troubles for systems using serial interrupt delivery over the
inter-APIC bus (the vector, delivery mode, etc. are generally not meant to
be changed with the input unmasked for these chips -- which just shows how
braindead the idea of the mask having side effects is).  Just a thought.

  Maciej
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/