From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 20 01:43:12 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 2D86B16A41F; Fri, 20 Jan 2006 01:43:12 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB75443D46; Fri, 20 Jan 2006 01:43:11 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: by ion.gank.org (mail, from userid 1001) id 3AFF22AA01; Thu, 19 Jan 2006 19:43:11 -0600 (CST) Date: Thu, 19 Jan 2006 19:43:07 -0600 From: Craig Boston To: freebsd-hackers@freebsd.org Message-ID: <20060120014307.GA3118@nowhere> Mail-Followup-To: Craig Boston , freebsd-hackers@freebsd.org, jhb@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: 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: Fri, 20 Jan 2006 01:43:12 -0000 After trying everything I could think of to do to the I/O APIC code and coming up empty, tonight I went back to the local APIC. I had previously ruled it out since the lapic timer interrupt continued to work fine even when the others stopped. However, adding some DELAY(1) calls at key points caused it to work, much like adding WITNESS does. I managed to get it down to a single change that makes APIC mode work on this laptop: --- local_apic.c.orig Thu Jan 19 18:32:37 2006 +++ local_apic.c Thu Jan 19 18:32:28 2006 @@ -599,4 +599,5 @@ lapic_eoi(void) { lapic->eoi = 0; + lapic->eoi = 0; } ...and welcome to bizarro world. There's absolutely no reason I can think of why that would change anything, other than buggy hardware. I looked at what Linux was doing, and they're also using a single write to EOI interrupts, so long as the X86_GOOD_APIC config option is enabled (and it is for P5/MMX or newer). Otherwise it does an extra read before writing to any APIC register. I don't know if linux works on this hardware or not -- the live CD I tried wasn't compiled for APIC support. At this point, since AFAIK nobody else has reported the same problem, I'm content with a local workaround. It's just... wierd. Craig