| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <87iqknp8a0.fsf@basil.nowhere.org> Date: Wed, 29 Apr 2009 21:30:31 +0200 From: Andi Kleen <andi@...stfloor.org> To: Borislav Petkov <borislav.petkov@....com> Cc: akpm@...ux-foundation.org, greg@...ah.com, <mingo@...e.hu>, <tglx@...utronix.de>, <hpa@...or.com>, <dougthompson@...ssion.com>, <linux-kernel@...r.kernel.org> Subject: Re: [RFC PATCH 00/21 v2] amd64_edac: EDAC module for AMD64 Borislav Petkov <borislav.petkov@....com> writes: > Hi, > > thanks to all reviewers of the previous submission, here is the second > version of this series. The classic problem of the previous versions of these patches was that they consume the same error registers (even if using pci config versus msrs as access methods) as the kernel machine check poll/threshold interrupt code. And with two logging agents racing on the same registers you will always get junk results. Typically with threshold enabled the mce code wins the race. I suspect this patchkit has exactly the same fundamental design problem. EDAC really is not particularly fitting for integrated memory controllers that report their errors using standard machine check events. -Andi (who thinks all of this decoding should be in user space anyways) -- ak@...ux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists