From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 6 21:49:23 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8BC616A420 for ; Tue, 6 Dec 2005 21:49:23 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 287B143D79 for ; Tue, 6 Dec 2005 21:49:09 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3275227 for multiple; Tue, 06 Dec 2005 16:49:18 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jB6Ln0Uu051148; Tue, 6 Dec 2005 16:49:03 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Craig Boston Date: Tue, 6 Dec 2005 15:20:30 -0500 User-Agent: KMail/1.8.2 References: <20051130020734.GA6577@nowhere> <20051206015129.GA34415@nowhere> <20051206035228.GA34979@nowhere> In-Reply-To: <20051206035228.GA34979@nowhere> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512061520.31168.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-hackers@freebsd.org Subject: Re: Weird PCI interrupt delivery problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2005 21:49:24 -0000 On Monday 05 December 2005 10:52 pm, Craig Boston wrote: > On Mon, Dec 05, 2005 at 07:51:29PM -0600, Craig Boston wrote: > > With the ACPI timer disabled (debug.acpi.disabled=timer), the ACPI+APIC > > case now behaves the same as the plain APIC case. Each IRQ gets > > anywhere from 10,000-500,000 interrupts before it simply stops working. > > And to follow up to myself yet again, the i8254 timecounter is also bad > news for APIC. Switching to it, with or without ACPI, causes things to > stop working really fast. > > Just a stab in the dark, but it sounds like there may be something > screwy going on in the interconnect between the I/O APIC and the 8259s. > I'm pretty familiar with old-style (ISA) design, but somewhat fuzzy on > exactly how those two normally coexist, especially when everything is > integrated together on a bridge chip somewhere. > > IIRC there used to be some mixed-mode hacks that have been cleaned up in > 6.0. Might Windows still be doing something similar and that's why it > works? No, Windows doesn't use mixed mode. That stuff only had to do with routing IRQ0 anyways. We use the lapic timer instead of IRQ0 now (as does Windows). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org