Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932568AbXBKWCO (ORCPT ); Sun, 11 Feb 2007 17:02:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932569AbXBKWCO (ORCPT ); Sun, 11 Feb 2007 17:02:14 -0500 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:40515 "EHLO ebiederm.dsl.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932568AbXBKWCN (ORCPT ); Sun, 11 Feb 2007 17:02:13 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Zwane Mwaikambo Cc: Ashok Raj , Ingo Molnar , Andrew Morton , linux-kernel@vger.kernel.org, "Lu, Yinghai" , Natalie Protasevich , Andi Kleen Subject: Re: What are the real ioapic rte programming constraints? References: <200701221116.13154.luigi.genoni@pirelli.com> <200702021848.55921.luigi.genoni@pirelli.com> <200702021905.39922.luigi.genoni@pirelli.com> <20070206073616.GA15016@elte.hu> <20070206222523.GA11602@elte.hu> Date: Sun, 11 Feb 2007 15:01:20 -0700 In-Reply-To: (Zwane Mwaikambo's message of "Sun, 11 Feb 2007 08:16:39 -0800 (PST)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1656 Lines: 41 Zwane Mwaikambo writes: > > The 7500 issue isn't actually a race but a disease, if you mask a pending > irq in its RTE, the PCI hub generates an INTx message corresponding to > that irq. This apparently was done to support booting OSes without APIC > support. So the following would occur; > > - irqN pending on IOAPIC > - mask > => INTx message for irqN > > Unfortunately it appears the below code would also be affected by this as > well, the appropriate reference is; > > 2.15.2 PCI Express* Legacy INTx Support and Boot Interrupt > http://download.intel.com/design/chipsets/datashts/30262802.pdf Ouch. And this kind of thing isn't exactly uncommon. However if we have the irqs also disabled in the i8259 we should be safe from actually receiving this interrupt (even if it generates bus traffic), and when we enable the irq since it is level triggered we should still get an interrupt message. It isn't immediately obvious where the i8259 irq enable/disable happens. So i"m having trouble auditing that bit of code. Plus we can get very strange things like the irq number changing and the sharing rules being different when going through the i8259. So irqN may be irqM when going through the i8259. As long as we aren't using anything on the i8259 including the timer in ExtINT mode we can disable every interrupt pin and not worry about interrupts from that source. Eric - 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/