Date: Tue, 13 Dec 2005 14:32:53 -0500 From: John Baldwin <jhb@freebsd.org> To: "Bjoern A. Zeeb" <bz@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: <200512131432.54944.jhb@freebsd.org> In-Reply-To: <20051213181035.R23668@maildrop.int.zabbadoz.net> References: <200512131509.jBDF9elC056262@repoman.freebsd.org> <20051213181035.R23668@maildrop.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200512131432.54944.jhb>