Date: Mon, 20 Apr 2015 08:25:07 +0200 From: Matthias Apitz <guru@unixarea.de> To: Marius Strobl <marius@alchemy.franken.de> Cc: freebsd-hackers@freebsd.org, Jeremy Chadwick <jdc@koitsu.org> Subject: Re: Fwd: kernel: MCA: CPU 0 COR (1) internal parity error Message-ID: <20150420062507.GA2640@c720-r276659> In-Reply-To: <20150419205217.GA3802@alchemy.franken.de> References: <20150118060843.GA1184@c720-r276659> <20150419205217.GA3802@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--0F1p//8PRICkK4MW Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit El día Sunday, April 19, 2015 a las 10:52:17PM +0200, Marius Strobl escribió: > On Sun, Jan 18, 2015 at 07:08:43AM +0100, Matthias Apitz wrote: > > > > Hello, > > > > I'm running since some days a recent -HEAD r276659 on an Acer C720 Chromebook > > which works very nicely and fast (I really have never seen such a fast KDE4 desktop). > > > > >From time to time (let's say 2-3 times a day) I see messages like this > > in /var/log/messages: > > > > Jan 16 12:04:24 c720-r276659 kernel: MCA: Bank 0, Status 0x90000040000f0005 > > Jan 16 12:04:24 c720-r276659 kernel: MCA: Global Cap 0x0000000000000c07, Status 0x0000000000000000 > > Jan 16 12:04:24 c720-r276659 kernel: MCA: Vendor "GenuineIntel", ID 0x40651, APIC ID 0 > > Jan 16 12:04:24 c720-r276659 kernel: MCA: CPU 0 COR (1) internal parity error > > > > <...> > > > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz 686-class CPU) > > Origin="GenuineIntel" Id=0x40651 Family=0x6 Model=0x45 Stepping=1 > > Apparently, this is the HSD131 or - more precisely - the HSM142 silicon > bug, although the specification update concerened with HSM142 [1] only > enlists CPU IDs 0x3c and 0x46 (actually, it only has identification > information for the M- and H-line of processors, but not the Y- and - > which Celeron 2955U belongs into - U-lines). Reporting should be gone > with r281751. > > Marius > > 1: http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/4th-gen-core-family-mobile-specification-update.pdf > Hello Marius, Thanks for a pointer to this explanation and bug fix. I pulled out mca.c of r281751 and the diff looks like I could simply update mca.c to this revision. Thanks matthias -- Matthias Apitz, guru@unixarea.de, http://www.unixarea.de/ +49-170-4527211 +49-176-38902045 "Wenn der Mensch von den Umständen gebildet wird, so muß man die Umstände menschlich bilden." "Si el hombre es formado por las circunstancias entonces es necesario formar humanamente las circunstancias", Karl Marx in Die heilige Familie / La sagrada familia (MEW 2, 138) --0F1p//8PRICkK4MW Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="mca.c.diff" *** x86/x86/mca.c 2015-01-06 08:21:59.000000000 +0100 --- /tmp/mca.c 2015-04-20 08:03:01.000000000 +0200 *************** *** 30,36 **** */ #include <sys/cdefs.h> ! __FBSDID("$FreeBSD: head/sys/x86/x86/mca.c 269242 2014-07-29 14:54:23Z marius $"); #ifdef __amd64__ #define DEV_APIC --- 30,36 ---- */ #include <sys/cdefs.h> ! __FBSDID("$FreeBSD$"); #ifdef __amd64__ #define DEV_APIC *************** *** 251,265 **** { /* ! * Skip spurious corrected parity errors generated by desktop Haswell ! * (see HSD131 erratum) unless reporting is enabled. ! * Note that these errors also have been observed with D0-stepping, ! * while the revision 014 desktop Haswell specification update only ! * talks about C0-stepping. */ ! if (rec->mr_cpu_vendor_id == CPU_VENDOR_INTEL && ! rec->mr_cpu_id == 0x306c3 && rec->mr_bank == 0 && ! rec->mr_status == 0x90000040000f0005 && !intel6h_HSD131) return (1); return (0); --- 251,274 ---- { /* ! * Skip spurious corrected parity errors generated by Intel Haswell- ! * and Broadwell-based CPUs (see HSD131, HSM142, HSW131 and BDM48 ! * erratum respectively), unless reporting is enabled. ! * Note that these errors also have been observed with the D0-stepping ! * of Haswell, while at least initially the CPU specification updates ! * suggested only the C0-stepping to be affected. Similarly, Celeron ! * 2955U with a CPU ID of 0x45 apparently are also concerned with the ! * same problem, with HSM142 only referring to 0x3c and 0x46. */ ! if (cpu_vendor_id == CPU_VENDOR_INTEL && ! CPUID_TO_FAMILY(cpu_id) == 0x6 && ! (CPUID_TO_MODEL(cpu_id) == 0x3c || /* HSD131, HSM142, HSW131 */ ! CPUID_TO_MODEL(cpu_id) == 0x3d || /* BDM48 */ ! CPUID_TO_MODEL(cpu_id) == 0x45 || ! CPUID_TO_MODEL(cpu_id) == 0x46) && /* HSM142 */ ! rec->mr_bank == 0 && ! (rec->mr_status & 0xa0000000ffffffff) == 0x80000000000f0005 && ! !intel6h_HSD131) return (1); return (0); --0F1p//8PRICkK4MW--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150420062507.GA2640>