Date: Tue, 13 Dec 2005 18:29:26 +0000 (UTC) From: "Bjoern A. Zeeb" <bz@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> 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 Message-ID: <20051213181035.R23668@maildrop.int.zabbadoz.net> In-Reply-To: <200512131509.jBDF9elC056262@repoman.freebsd.org> References: <200512131509.jBDF9elC056262@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <Nvidia AWRDACPI>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051213181035.R23668>