From owner-freebsd-current@FreeBSD.ORG Thu Apr 7 06:52:13 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A53C516A4CE for ; Thu, 7 Apr 2005 06:52:13 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A54043D45 for ; Thu, 7 Apr 2005 06:52:13 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 5280D72DDB; Wed, 6 Apr 2005 23:52:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 4E15272DD9 for ; Wed, 6 Apr 2005 23:52:13 -0700 (PDT) Date: Wed, 6 Apr 2005 23:52:13 -0700 (PDT) From: Doug White To: freebsd-current@freebsd.org Message-ID: <20050406233405.O47071@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2005 06:52:13 -0000 Hey folks, After looking at Intel docs for the last several days I've uncovered what may be the source of our interrupt aliasing problem. In order to support non-APIC mode operation, IOAPICs servicing other PCI busses than the primary in the system support so-called "boot interrupt" operation. In this mode (which is enabled by default) if they receive an interrupt and it is masked in the IOAPIC (again the default), it will trigger the boot interrupt signal instead. This signal is usually a dedicated pin on the bridge and is attached to the IOAPIC in the ICH that also gets the ISA interrupts from the 8259s. In the Intel WV2 board, the boot interrupt line from the P64H2 PCI-PCI bridge is tied to PIRQA on the ICH -- which is tied to intpin 16 on its IOAPIC. Typically the USB controllers are mapped to this IRQ as well. Where this becomes a problem is our strategy of masking interrupts in the IOAPIC for devices whose ithread is active. If the same device interrupts again, its interrupt is diverted over the boot interrupt signal (because its masked) and shows up as an interrupt on IRQ16. The docs _imply_ that this is supposed to be disabled when APIC mode is enabled, but I don't think thats the case for most chipsets. The Intel P64H2 and PXH PCI-PCI bridge docs I've read don't have a disable register, although newer IO hubs (like the 6300ESB) do to quell it on their interrupt sources. A quick hack would be to blacklist intpin 16 on the first IOAPIC and bump any PCI devices that ACPI says are claiming that interrupt. I don't know how difficult this is to do with ACPI. How to handle this for ATPIC mode is a little difficult since the boot interrupt either gets routed to IRQ9 or ends up as a stray on IRQ7 (on my SCB2 at least -- other boards may vary). If anyone else has thought this through and can prove me wrong, please do so ... its late and my brain hurts from reading Intel docs :-) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org