Messages in this thread | | | Date | Wed, 4 Jun 2008 18:08:49 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [PATCH 0/7] Boot IRQ quirks and rerouting |
| |
On Wed, 4 Jun 2008, Maciej W. Rozycki wrote: > On Wed, 4 Jun 2008, Stefan Assmann wrote: > What's the reasoning behind the option in this case? As I understand > there are two cases possible: > > 1. Secondary, etc. I/O APIC inputs are not masked under any circumstances. > No legacy INTx redirection happens, nothing to be done. > > 2. Secondary, etc. I/O APIC inputs are to be masked from time to time. > That would cause legacy INTx redirection for the affected chipsets in > situations where an interrupt arrives at a masked I/O APIC input. This > interrupt is delivered to an input of the primary I/O APIC which cannot > be masked because of other devices wired to it. > > OK -- that means the interrupt is delivered anyway (and perhaps > discarded in the handler, but that does not matter here), so why to do
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.
What happens is:
irq_disable(secondary);
irq line of the secondary ioapic becomes active
legacy irq happens
repeat: legacy irq disable handler runs and discards legacy irq enable
legacy interrupt is still active due to rerouting if (count < max) goto repeat else disable legacy irq forever
Thanks, tglx
| |