From owner-cvs-all@FreeBSD.ORG Tue Dec 13 19:36:52 2005 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43F3816A420; Tue, 13 Dec 2005 19:36:52 +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 9043A43D5A; Tue, 13 Dec 2005 19:36:50 +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 3733877 for multiple; Tue, 13 Dec 2005 14:39:04 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBDJakYx050353; Tue, 13 Dec 2005 14:36:46 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Bjoern A. Zeeb" Date: Tue, 13 Dec 2005 14:32:53 -0500 User-Agent: KMail/1.8.2 References: <200512131509.jBDF9elC056262@repoman.freebsd.org> <20051213181035.R23668@maildrop.int.zabbadoz.net> In-Reply-To: <20051213181035.R23668@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512131432.54944.jhb@freebsd.org> X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on server.baldwin.cx X-Virus-Status: Clean 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: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/i386/i386 local_apic.c src/sys/amd64/amd64 local_apic.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2005 19:36:52 -0000 On Tuesday 13 December 2005 01:29 pm, Bjoern A. Zeeb wrote: > On Tue, 13 Dec 2005, John Baldwin wrote: > > jhb 2005-12-13 15:09:40 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/i386/i386 local_apic.c > > sys/amd64/amd64 local_apic.c > > Log: > > Don't check the CPUID_APIC bit in the cpu_features flags field to > > determine if the boot CPU has a local APIC because some BIOS vendors are > > not competent enough to set this bit. Instead, just assume that we > > always have a local APIC on amd64. > > ... > > > Reported by: bz > > 1) for the records find more information about the board/BIOS > in question in PR 88251. > > 2) though the above initially sounded like it might be a good idea > because FreeBSD is smart enough to find everything even if that bit > isn't set: > > CPI APIC Table: > APIC: CPU 0 has ACPI ID 0 > MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 > ioapic0: Changing APIC ID to 2 > ... > ioapic0: intpin 15 polarity: high > lapic0: Routing NMI -> LINT1 > MADT: Ignoring local NMI routed to ACPI CPU 1 None of this is problematic actually. The 'Ignoring' line indicates a bug in your BIOS, but not one that is harmful. > the next problem turned up later at boot time: > > ... > procfs registered > linprocfs registered > panic: lapic: Divisor too big > KDB: enter: panic > [thread pid 0 tid 0 ] > Stopped at kdb_enter+0x31: leave > db> where > Tracing pid 0 tid 0 td 0xffffffff808e1bc0 > kdb_enter() at kdb_enter+0x31 > panic() at panic+0x179 > lapic_setup_clock() at lapic_setup_clock+0x99 > cpu_initclocks() at cpu_initclocks+0xe > initclocks() at initclocks+0x9 > mi_startup() at mi_startup+0xb6 > btext() at btext+0x2c This means your local APIC doesn't actually work and is why I backed it out altogether. :( > The more I think about it the more I like the idea from obrien@ to > panic if the CPUID_APIC bit isn't set on amd64 and tell the user to get > their BIOS (settings) fixed. It will save us a lot of debugging trouble > like I already caused and will hopefully make more users complain to > their board/BIOS vendors to get it fixed. WinXP64 gives a nice text blob > to tell the user exactly that. If we get too many reports it'll be a FAQ. Well, what we have now would just work out of the box if atpic is in the kernel. APIC is mandatory for amd64 though, and if Windows blows chunks on it I'm sure BIOS vendors will eventually fix it. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org