Re: [PATCH v2 0/6] CPER: Add Memory Error Section 2 support
From: Pierre Gondois
Date: Fri Oct 30 2026 - 13:16:53 EST
On 10/30/26 16:19, Jonathan Cameron wrote:
On Fri, 30 Oct 2026 12:51:47 +0100
Pierre Gondois <pierre.gondois@xxxxxxx> wrote:
On 10/25/26 00:05, Ashok Raj wrote:We have will have a code first proposal for the _OSC part shortly. Just going
On Fri, Oct 23, 2026 at 05:04:05PM -0700, Jonathan Cameron wrote:I understand we might want to emit a new extlog_mem2_event and a lossy
On Sat, 24 Oct 2026 00:40:33 +0200Hi Jonathan,
Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> wrote:
On Fri, 23 Oct 2026 14:26:21 -0700Good. That confirms my view that is horrible.
Jonathan Cameron <jonathan.cameron@xxxxxxxxxxxxxxxx> wrote:
On Thu, 22 Oct 2026 09:07:25 +0200Please don't do this: this would require either Kernespace or userspace to
Pierre Gondois <pierre.gondois@xxxxxxx> wrote:
On 10/20/26 19:10, Jonathan Cameron wrote:A general question that came up in a related thread with one of
On Mon, 19 Oct 2026 22:38:39 +0200Hello Jonathan,
Pierre Gondois <pierre.gondois@xxxxxxx> wrote:
The support is mostly duplicated from Memory Error Section handling.Hi Pierre,
Other than differences coming from the content of Memory Error
Section 1 and 2, differences in the support are:
- v2 do not rely on a compact "struct cper_mem_err_compact" struct.
This structure was used to support older versions of the Memory
Error Section (1). This is not needed for the new structure.
- The compact version is also used by the tracing framework.
To avoid relying and propagating a non-standard record format,
through trace event (cf. extlog_mem event) the new trace event
prints each field individually.
The last patch of the serie was only build-tested due to the
absence of relevant hardware. apei_mce_report_mem_error() and
arch_apei_report_mem_error() implementations were also removed since
last version.
It will also require a proper handling from the rasdaemon. Applying
this last patch without rasdaemon support will silent the reports of
Memory Error Section 2 error, cf. ras_userspace_consumers() check.
I'd slow down a bit. We are mid merge window and convention is normally
one version a week or so anyway. Better to gather up feedback from
a number of folk and spin only one revision to cover it all.
Ok sure, as the v1 was reviewed quickly I thought there was a chance
of having the serie accepted quickly aswell. I ll wait a bit more.
Thanks for the review,
Pierre
our RAS architects. How does firmware decide what to send? As far as
I can tell firwmare has no way to know whether the OS understands the CPER
Memory Section 2.
So options that come to mind.
1. Firmware must send a CPER with both Memory Section and Memory Section 2.
discard one of the reports, only if the other one is there, which can be
tricky. Could be done more easily at userspace, but only if some database
support is enabled, but, at least on rasdaemon, this is an optional module.
I agree that an _OSC capability is the right long-term solution.
Firmware should select one native CPER format based on OS support, rather
than emit both Section 1 and Section 2 and leave deduplication to the OS
or userspace.
For a Section 2-capable kernel, we may still avoid a second GHES notifier
chain: preserve the existing struct cper_sec_mem_err * contract and give
it a lossy Section 1 projection of a Section 2 record. The conversion must
translate validation bits and clear validity for values that cannot be
represented, rather than truncate them.
extlog_mem_event for legacy userspace, but I'm not sure to follow how
you want to do it.
Do you suggest that we only need one notifier (ghes_report_mem_chain)
and that we should not add ghes_report_mem2_chain ? This would mean
that the .notifier_call (= ghes_edac_report_mem_error) should handle
both cper_sec_mem_err/cper_sec_mem_err2 struct.
Another solution would be to keep the ghes_report_mem2_chain,
which would be responsible of creating the lossy v1 struct and
triggering the original ghes_report_mem_chain.
That preserves legacy EDAC consumers, but cannot carry all Section 2 data.This will put more burden on the firmware, but this seems the right
Updated userspace needs the native Section 2 payload through a
full-fidelity path, such as the existing GUID-tagged raw CPER event.
This does mean an updated userspace listener may receive both the legacy
EDAC summary and the raw Section 2 record for the same firmware error.
They are two kernel views, not two firmware reports. We should therefore
add a shared GHES record/section ID to both events, so userspace can
correlate them reliably; address and timestamp are not sufficient.
So _OSC solves firmware selection for old versus new kernels, while a
Section 1 projection plus the raw payload handles legacy versus updated
consumers on a new kernel.
Thoughts?
thing to do. I ll share the thread with the group working more closely
on the architecture aswell,
through internal review. I'll make sure you + others here are on the +CC.
Ok thanks,
If you can also also add Mark Brown <broonie@xxxxxxxxxx>