From: Yazen Ghannam <yazen.ghannam@amd.com>
To: Adrian Schlegel <me@adrianschlegel.com>
Cc: tony.luck@intel.com, bp@alien8.de, x86@kernel.org,
linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] x86/mce: Do not treat cache hierarchy errors as memory errors
Date: Mon, 19 Oct 2026 11:32:07 -0400 [thread overview]
Message-ID: <20261019153207.GA144824@yaz-khff2.amd.com> (raw)
In-Reply-To: <20261012193305.38931-1-me@adrianschlegel.com>
On Mon, Oct 12, 2026 at 09:33:05PM +0200, Adrian Schlegel wrote:
> On Intel and Zhaoxin, mce_is_memory_error() also returns true for cache
> hierarchy errors. All callers expect it to report memory errors only.
>
> The CEC uses it to count corrected DRAM errors. A corrected cache error
> only names the cache line that was affected, not a faulty DRAM page.
> With a faulty CPU core, the CEC therefore soft-offlines healthy pages.
> On an i9-9900K this caused about 500 soft-offline attempts per hour.
>
> Report only memory controller errors on Intel and Zhaoxin, as is
> already done for AMD.
>
> Fixes: fa92c5869426 ("x86, mce: Support memory error recovery for both UCNA and Deferred error in machine_check_poll")
> Signed-off-by: Adrian Schlegel <me@adrianschlegel.com>
> ---
> v3:
> - Shorten and wrap commit message (Boris, Tony)
> - Refer to the SDM section by name instead of number (Tony)
>
> v2:
> - Fix mce_is_memory_error() itself instead of adding a CEC-local helper (Tony)
> - v1: https://lore.kernel.org/r/20260927151904.30524-1-me@adrianschlegel.com
>
> Tested with mce-inject (sw) in a VM with an Intel CPU model. A corrected
> cache error (status 0xcc5ffc0000100179) is no longer counted and its
> page stays online. A corrected memory controller error (status
> 0x8c0000000000009f) is still counted and its page soft-offlined.
>
> arch/x86/kernel/cpu/mce/core.c | 18 +++++-------------
> 1 file changed, 5 insertions(+), 13 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
> index ab469605f..54ed053fa 100644
> --- a/arch/x86/kernel/cpu/mce/core.c
> +++ b/arch/x86/kernel/cpu/mce/core.c
> @@ -540,21 +540,13 @@ bool mce_is_memory_error(struct mce *m)
> case X86_VENDOR_INTEL:
> case X86_VENDOR_ZHAOXIN:
> /*
> - * Intel SDM Volume 3B - 15.9.2 Compound Error Codes
> + * Intel SDM Volume 3B "Compound Error Codes".
> *
> - * Bit 7 of the MCACOD field of IA32_MCi_STATUS is used for
> - * indicating a memory error. Bit 8 is used for indicating a
> - * cache hierarchy error. The combination of bit 2 and bit 3
> - * is used for indicating a `generic' cache hierarchy error
> - * But we can't just blindly check the above bits, because if
> - * bit 11 is set, then it is a bus/interconnect error - and
> - * either way the above bits just gives more detail on what
> - * bus/interconnect error happened. Note that bit 12 can be
> - * ignored, as it's the "filter" bit.
> + * Memory controller errors have an MCACOD of 000F 0000 1MMM CCCC:
> + * bit 7 set, bits 8-11 and 13-15 clear. Bit 12 is the "filter"
> + * bit and is ignored.
> */
> - return (m->status & 0xef80) == BIT(7) ||
> - (m->status & 0xef00) == BIT(8) ||
> - (m->status & 0xeffc) == 0xc;
> + return (m->status & 0xef80) == BIT(7);
>
The SDM also mentions "Extended Memory Errors". I guess these were left
out before, but should they be included?
Thanks,
Yazen
next prev parent reply other threads:[~2026-10-19 15:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-27 15:19 [PATCH] RAS/CEC: Only count corrected DRAM errors on Intel Adrian Schlegel
2026-09-27 18:14 ` Borislav Petkov
2026-09-29 19:01 ` Luck, Tony
2026-10-03 22:20 ` [PATCH v2] x86/mce: Do not treat cache hierarchy errors as memory errors Adrian Schlegel
2026-10-03 23:17 ` Borislav Petkov
2026-10-05 15:30 ` Luck, Tony
2026-10-12 19:33 ` [PATCH v3] " Adrian Schlegel
2026-10-13 0:01 ` Luck, Tony
2026-10-13 1:04 ` Qiuxu (Leo) Zhuo
2026-10-19 15:32 ` Yazen Ghannam [this message]
2026-10-19 18:34 ` Adrian Schlegel
2026-10-19 18:42 ` Yazen Ghannam
2026-10-19 20:45 ` Sohil Mehta
2026-10-19 21:06 ` Luck, Tony
2026-10-20 17:09 ` Sohil Mehta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261019153207.GA144824@yaz-khff2.amd.com \
--to=yazen.ghannam@amd.com \
--cc=bp@alien8.de \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=me@adrianschlegel.com \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.