Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760148AbYFDRTV (ORCPT ); Wed, 4 Jun 2008 13:19:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752744AbYFDRTJ (ORCPT ); Wed, 4 Jun 2008 13:19:09 -0400 Received: from kirk.serum.com.pl ([213.77.9.205]:63929 "EHLO serum.com.pl" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752009AbYFDRTI (ORCPT ); Wed, 4 Jun 2008 13:19:08 -0400 Date: Wed, 4 Jun 2008 18:18:28 +0100 (BST) From: "Maciej W. Rozycki" To: Thomas Gleixner 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> 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: 1839 Lines: 33 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/