From owner-freebsd-current@FreeBSD.ORG Fri Apr 8 21:26:09 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 8658916A4FD for ; Fri, 8 Apr 2005 21:26:09 +0000 (GMT) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17E4A43D2D for ; Fri, 8 Apr 2005 21:26:09 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 30308 invoked from network); 8 Apr 2005 21:26:08 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 8 Apr 2005 21:26:08 -0000 Received: from roboboy.corp.weather.com (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j38LPkgr091046; Fri, 8 Apr 2005 17:26:02 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Fri, 8 Apr 2005 16:56:50 -0400 User-Agent: KMail/1.8 References: <20050406233405.O47071@carver.gumbysoft.com> In-Reply-To: <20050406233405.O47071@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504081656.51917.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx Subject: Re: 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: Fri, 08 Apr 2005 21:26:09 -0000 On Thursday 07 April 2005 02:52 am, Doug White wrote: > 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). You can't just move APIC interrupts around. They are physically wired that way. ATPIC mode won't matter. If there is a way to disable this in hardware, then it needs to be done in the _PIC method of the BIOS for ACPI. I don't think there's any way to allow for this for non-ACPI though as the MPTable spec only mentions the IMCR which these boards don't implement. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org