From owner-cvs-all@FreeBSD.ORG Tue Dec 13 18:32:38 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 9ED5F16A41F; Tue, 13 Dec 2005 18:32:38 +0000 (GMT) (envelope-from bz@FreeBSD.org) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id B727F43D60; Tue, 13 Dec 2005 18:32:37 +0000 (GMT) (envelope-from bz@FreeBSD.org) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id B176E1FFDD8; Tue, 13 Dec 2005 19:32:36 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 0B2A71FFDD3; Tue, 13 Dec 2005 19:32:33 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id ED22B444F50; Tue, 13 Dec 2005 18:29:26 +0000 (UTC) Date: Tue, 13 Dec 2005 18:29:26 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: John Baldwin In-Reply-To: <200512131509.jBDF9elC056262@repoman.freebsd.org> Message-ID: <20051213181035.R23668@maildrop.int.zabbadoz.net> References: <200512131509.jBDF9elC056262@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de 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 18:32:38 -0000 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 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 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. 3) In case anyone else suffers from same problem: I managed to get the machine booted because I still had atpic in kernel (no longer in by default). For the above problem I thus could set hint.apic.0.disabled="1" in loader to work around the panic. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT