Re: [PATCH v2 0/6] CPER: Add Memory Error Section 2 support

[Jonathan Cameron]

On Sat, 24 Oct 2026 00:40:33 +0200
Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> wrote:

> On Fri, 23 Oct 2026 14:26:21 -0700
> Jonathan Cameron <jonathan.cameron@xxxxxxxxxxxxxxxx> wrote:
> 
> > On Thu, 22 Oct 2026 09:07:25 +0200
> > Pierre Gondois <pierre.gondois@xxxxxxx> wrote:
> >   
> > > On 10/20/26 19:10, Jonathan Cameron wrote:    
> > > > On Mon, 19 Oct 2026 22:38:39 +0200
> > > > Pierre Gondois <pierre.gondois@xxxxxxx> wrote:
> > > >      
> > > >> The support is mostly duplicated from Memory Error Section handling.
> > > >> 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.      
> > > > Hi Pierre,
> > > >
> > > > 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.
> > > >      
> > > Hello Jonathan,
> > > 
> > > 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
> > >     
> > 
> > A general question that came up in a related thread with one of
> > 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.  
> 
> Please don't do this: this would require either Kernespace or userspace to
> 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.

Good. That confirms my view that is horrible.

> 
> > 2. For whatever other reason a platform knows it doesn't work with old kernel
> >    so can assume support in kernel and hopefully userspace got updated too.
> > 
> > 3. We propose some additional discoverability (quickly - code first) to ACPI
> >    so that it can be a negotiated contract between OS and firmware.
> >    Until the OS confirms it understands Memory Section 2, firmware has to send
> >    the older one (or risk the record not being understood).  After that
> >    negotiation it can do what it likes - probably send the Memory Section 2 form.
> > 
> > Option 1 and 2 are ugly at best.
> > 
> > Obvious path to me for option 3 is an _OSC like the one for generic initiators
> > that we discovered a need for whilst implementing that years ago.
> > 
> > Anyhow have a better idea?  The above doesn't solve the end to end problem as
> > maybe userspace still has no idea what this new tracepoint is, but at least gets
> > us past hop 1 (so through the kernel). 
> > 
> > If we conclude _OSC plan works I'll draft a code first proposal.
> > 
> > Jonathan  

On another note, Pierre, any plans to actually enable a path to the tracepoints
on arm64?  Today they only emerge from acpi_extlog which is x86 only.

We definitely want the richer data for PFA and obviously for userspace nice
to share tracepoints with extlog.  

Jonathan


> 
> Regards,
> Mauro