[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB60838F74FA06ED06C5D29FEDFC51A@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Thu, 17 Jul 2025 17:19:48 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Breno Leitao <leitao@...ian.org>, Shuai Xue <xueshuai@...ux.alibaba.com>
CC: 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
>> Personally, I think this approach would be more helpful. Additionally, I
>> suggest not mixing CEs (Correctable Errors) and UEs (Uncorrectable
>> Errors) together. This is especially important for memory errors, as CEs
>> occur much more frequently than UEs, but their impact is much smaller.
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.
-Tony
Powered by blists - more mailing lists