[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB6083D0B2B8AA0C056A1B4F7BFC51A@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Thu, 17 Jul 2025 17:54:13 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Breno Leitao <leitao@...ian.org>
CC: Shuai Xue <xueshuai@...ux.alibaba.com>, Borislav Petkov <bp@...en8.de>,
"Graf, Alexander" <graf@...zon.com>, Konrad Rzeszutek Wilk
<konrad.wilk@...cle.com>, Peter Gonda <pgonda@...gle.com>, "Rafael J.
Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>, James Morse
<james.morse@....com>, "Moore, Robert" <robert.moore@...el.com>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"acpica-devel@...ts.linux.dev" <acpica-devel@...ts.linux.dev>,
"kernel-team@...a.com" <kernel-team@...a.com>
Subject: RE: [PATCH] ghes: Track number of recovered hardware errors
>> Total agreement on keeping corrected memory errors out of this special
>> handling. They happen all the time in a large fleet, and are not significant
>> unless the same address repeats.
>
> Are these EDAC errors? Shouldn't we track CE errors in
> edac_device_handle_ce_count()?
Existing code should already handle this. EDAC drivers register
with mce_register_injector_chain() to be told of memory errors.
-Tony
Powered by blists - more mailing lists