[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB6083A8D348C9DAB38444B2EFFCCD2@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Thu, 27 Feb 2025 18:01:36 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Zhuo, Qiuxu" <qiuxu.zhuo@...el.com>, Borislav Petkov <bp@...en8.de>,
Jason Baron <jbaron@...mai.com>
CC: James Morse <james.morse@....com>, Mauro Carvalho Chehab
<mchehab@...nel.org>, Robert Richter <rric@...nel.org>, "Wang, Gary C"
<gary.c.wang@...el.com>, "Lai, Yi1" <yi1.lai@...el.com>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 11/11] EDAC/ie31200: Switch Raptor Lake-S to interrupt
mode
> Raptor Lake-S SoCs notify memory errors via Machine Check. Add interrupt
> mode support and switch Raptor Lake-S EDAC from polling to interrupt mode.
Is this notification #MC (a.k.a. INT#18)? Or CMCI? Or #MC for uncorrected errors
and CMCI for corrected errors?
Corrected errors -> CMCI I can understand. This code should work well for that.
Same for uncorrected patrol scrub errors -> CMCI.
Other uncorrected errors -> #MC is trickier. Does Raptor Lake support recovery
from other uncorrected errors? If it doesn't, then this driver handler will not be
called (Linux panicked and never called the functions registered on the mce
decode chain).
Which is perhaps a long way of asking whether you really mean:
Raptor Lake-S SoCs notify memory errors via CMCI. Add interrupt
mode support and switch Raptor Lake-S EDAC from polling to interrupt mode.
-Tony
Powered by blists - more mailing lists