Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753856AbYFDQKR (ORCPT ); Wed, 4 Jun 2008 12:10:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751916AbYFDQKB (ORCPT ); Wed, 4 Jun 2008 12:10:01 -0400 Received: from www.tglx.de ([62.245.132.106]:55555 "EHLO www.tglx.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752155AbYFDQJt (ORCPT ); Wed, 4 Jun 2008 12:09:49 -0400 Date: Wed, 4 Jun 2008 18:08:49 +0200 (CEST) From: Thomas Gleixner To: "Maciej W. Rozycki" cc: Stefan Assmann , "Eric W. Biederman" , Olaf Dabrunz , Ingo Molnar , "H. Peter Anvin" , Jon Masters , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/7] Boot IRQ quirks and rerouting In-Reply-To: Message-ID: References: <12124107071847-git-send-email-od@suse.de> <4846651F.4070802@suse.de> <48467DA7.9030309@suse.de> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1664 Lines: 47 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/