Date: Tue, 1 Mar 2011 19:02:05 -0800 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Mike Tancsa <mike@sentex.net> Cc: FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, John Baldwin <jhb@freebsd.org> Subject: Re: CPU0: local APIC error 0x40 CPU1: local APIC error 0x40 Message-ID: <20110302030205.GA51668@icarus.home.lan> In-Reply-To: <4D6DAC5A.6080904@sentex.net> References: <4D6DA259.4050307@sentex.net> <20110302020412.GA50962@icarus.home.lan> <4D6DAC5A.6080904@sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 01, 2011 at 09:32:58PM -0500, Mike Tancsa wrote: > On 3/1/2011 9:04 PM, Jeremy Chadwick wrote: > > On Tue, Mar 01, 2011 at 08:50:17PM -0500, Mike Tancsa wrote: > >> I had a machine deadlock just now and the only thing on the serial > >> console was > >> > >> CPU0: local APIC error 0x40 > >> CPU1: local APIC error 0x40 > > > > The error in question I'm not familiar with, but the code in > > src/sys/x86/x86/local_apic.c indicates that 0x40 is the contents of the > > LAPIC ESR (error status register). > > > > Please provide full output from a verbose boot. > > Attached as a .txt file Thanks -- this will probably be helpful to other folks, not so much me. :-) I lack familiarity with I/O and local APIC configuration. The error strings in question aren't shown in the attached text file, strangely enough. Maybe only visible on VGA console? Based on what I can find in Intel specifications, bit 6 (0x40) of the ESR is defined as: Bit 6: Receive Illegal Vector Set when the local APIC detects an illegal vector (one in the range 0 to 15) in an interrupt message it receives or in an interrupt generated locally from the local vector table or via a self IPI. Such interrupts are not be delivered to the processor; the local APIC will never set an IRR bit in the range 0 to 15. I got this from Section 10.5.3 of Intel's IA-32 Intel Architecture Software Developer's Manual, Volume 3A: http://developer.intel.com/design/processor/manuals/253668.pdf The motherboard looks like a Supermicro X7SBA or something along those lines (I can tell from the ACPI string). A workaround might be to disable multiprocessor support in the BIOS (specifically Advanced -> Advanced Processor Options -> Core-Multi-Processing = Disabled). If this does work, note that I agree it's not an acceptable permanent solution. CC'ing John who might have some ideas about the LAPIC stuff. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110302030205.GA51668>