cvs commit: src/sys/i386/i386 local_apic.c src/sys/amd64/amd64 local_apic.c

[John Baldwin]

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: <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

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 <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org