From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 24 15:43:02 2006 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 B670B16A420 for ; Tue, 24 Jan 2006 15:43:02 +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 0EB1D43D5F for ; Tue, 24 Jan 2006 15:43:01 +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 6850351 for multiple; Tue, 24 Jan 2006 10:44:10 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k0OFgtqE012691; Tue, 24 Jan 2006 10:42:58 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Craig Boston Date: Tue, 24 Jan 2006 10:43:49 -0500 User-Agent: KMail/1.9.1 References: <20060120014307.GA3118@nowhere> <200601201542.23464.jhb@freebsd.org> <20060124022511.GA99552@nowhere> In-Reply-To: <20060124022511.GA99552@nowhere> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601241043.51094.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1248/Tue Jan 24 05:54:38 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-hackers@freebsd.org, Scott Long Subject: Re: Weird PCI interrupt delivery problem (resolution, sort of) 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, 24 Jan 2006 15:43:02 -0000 On Monday 23 January 2006 21:25, Craig Boston wrote: > On Fri, Jan 20, 2006 at 03:42:21PM -0500, John Baldwin wrote: > > On Thu, Jan 19, 2006 at 10:17:39PM -0700, Scott Long wrote: > > > This points to a bus coherency problem. I wonder if your BIOS is > > > incorrectly setting the memory region of the apics as cachable. You'll > > > want to bug Baldwin about this. > > > > Hmm, well, you can actually try the PAT patch if you are feeling brave as > > it maps all devices (including APICs) as uncacheable. > > Tried the updated PAT patch (with s/pmap_unmapbios/pmap_unmap_bios/ to > get ACPI to compile). Unfortunately if it is a caching problem, PAT > isn't able to fix it. Same result as stock kernel -- interrupts stop > arriving after a dozen or so. AFAICT the local APIC is the only > memory-mapped I/O region that seems to be problematic. Ok. > Instead of writing the value twice, I also tried inserting an > __asm("nop") before the write with no effect. Also, a single write to > an unrelated area doesn't help: > > +static volatile int dummyeoi; > + > lapic_eoi(void) > { > > + dummyeoi = 1; > lapic->eoi = 0; > + dummyeoi = 2; > } > > I'm _reasonably_ certain that marking dummyeoi volatile and leaving it > uninitialized will prevent gcc from optimizng that out. Forcing R/W > cycles (++dummyeoi) before and after doesn't work either. > > A DELAY(1) before the lapic->eoi write does the trick, but DELAY does > lots of complicated things so I don't know how useful of a data point > that is. > > I'm probably missing something, but if bad cache behavior was causing > writes to the lapic EOI register to not always take effect, wouldn't the > _next_ irq (even if it's a different line) cause the one that's > currently pending to be acknowledged? What if you do a read of the lapic before the write? Maybe doing 'x = lapic->eoi; lapic->eoi = 0;'? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org