From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 16 16:10:29 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 756E916A41F for ; Wed, 16 Nov 2005 16:10:29 +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 318AD43D49 for ; Wed, 16 Nov 2005 16:10:27 +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 2066458 for multiple; Wed, 16 Nov 2005 11:10:03 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jAGG9tVV001642; Wed, 16 Nov 2005 11:09:55 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 16 Nov 2005 11:10:02 -0500 User-Agent: KMail/1.8.2 References: <20051116104819.GA10128@diogenis.ceid.upatras.gr> In-Reply-To: <20051116104819.GA10128@diogenis.ceid.upatras.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511161110.02750.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: Nikos Ntarmos Subject: Re: Bogus ioapic entry 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: Wed, 16 Nov 2005 16:10:29 -0000 On Wednesday 16 November 2005 05:48 am, Nikos Ntarmos wrote: > Hi all. > > I spent a couple of hours last night trying to get ACPI to function > correctly on my new Acer Aspire 1692WLMi. I found out that with apic > enabled, the system hangs when returning from S3, while with apic > disabled it suffers from interrupt storms on irq9 and the screen is not > reinitialized on return from S3 (with hw.acpi.reset_video set to both > "0" and "1"). While trying to hunt this thing down, I noticed that the > GENERIC kernel of 6.0-STABLE (and probably of other branches as well) > incorrectly discovers two ioapic devices: > > ioapic1: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-23 on motherboard > > There is something obviously wrong with ioapic1. The cause seems to be > the handling of value and numintr in ioapic_create(...). value is a > uint32_t, while numintr is a u_int, both of which are 32-bits long (per > and at least on my i386). The code in > ioapic_create(...), after the call to ioapic_read(apic, IOAPIC_VER), > uses the latter's return value to compute the number of interrupts > assigned to the current ioapic. This return value is checked against > 0xffffff (that's 24 1-bits) to detect an error and bail out. This code > chunk is also in -current (so perhaps I'm missing something here...) > > The (buggy?) BIOS implementation of my laptop returns a value of > 0xffffffff (32 1-bits) in ioapic_read(...). This, however, doesn't > trigger the current if-clause, so the code proceeds and creates ioapic1 > with -1(!) assigned IRQs (due to the and-and-shift-plus-one formula of > computing numintr). > > The attached diff fixes this situation and seems more correct to me than > the current code, given that io_numintr is 8 bits and u_int is 32 bits > per C standard. The problems with resuming from S3 > still haunt me though. I guess I should have a look at acpi@ later > today... > > Cheers. > > \n\n How about this diff instead. It is supposed to be explicitly checking for -1 since a read of an invalid memory or device location returns -1. I just typo'd and didn't put the right value in for the check. Index: io_apic.c =================================================================== RCS file: /usr/cvs/src/sys/i386/i386/io_apic.c,v retrieving revision 1.23 diff -u -r1.23 io_apic.c --- io_apic.c 2 Nov 2005 20:11:47 -0000 1.23 +++ io_apic.c 16 Nov 2005 16:09:19 -0000 @@ -502,7 +502,7 @@ mtx_unlock_spin(&icu_lock); /* If it's version register doesn't seem to work, punt. */ - if (value == 0xffffff) { + if (value == 0xffffffff) { pmap_unmapdev((vm_offset_t)apic, IOAPIC_MEM_REGION); return (NULL); } -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org