Linux CXL
 help / color / mirror / Atom feed
From: Dave Jiang <dave.jiang@intel.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: linux-cxl@vger.kernel.org, dave@stgolabs.net,
	alison.schofield@intel.com, ming.li@zohomail.com,
	icheng@nvidia.com
Subject: Re: [PATCH] cxl/mbox: Store event records for EDAC repair regardless of tracing
Date: Fri, 25 Sep 2026 16:52:47 -0700	[thread overview]
Message-ID: <0f3b2ed5-d797-4914-b4bc-e0e83475ee42@intel.com> (raw)
In-Reply-To: <20260926005053.4c823321@jic23-hlaptop>



On 9/25/26 4:50 PM, Jonathan Cameron wrote:
> On Fri, 25 Sep 2026 15:53:23 -0700
> Dave Jiang <dave.jiang@intel.com> wrote:
> 
>> On 9/25/26 3:44 PM, Jonathan Cameron wrote:
>>> On Thu, 24 Sep 2026 14:23:20 -0700
>>> Dave Jiang <dave.jiang@intel.com> wrote:
>>>   
>>>> The driver throws away media error records unless a tracepoint is enabled.
>>>>
>>>> cxl_event_trace_record() stores general media and DRAM records for EDAC
>>>> repair, but both calls sit inside a block gated on the cxl_general_media
>>>> and cxl_dram tracepoints. That gate only exists to skip the DPA-to-HPA
>>>> lookup used to annotate those tracepoints. Storing a record does not need
>>>> the lookup.
>>>>
>>>> With both tracepoints off, two things break. The kernel clears the device
>>>> event log either way, so the records are destroyed in hardware and kept
>>>> nowhere else. And live repair stops working altogether: sPPR and memory
>>>> sparing require the target DPA to have reported an error, no DPA ever has
>>>> a record, so every request fails with -EINVAL.  
>>>
>>> Hi Dave,
>>>
>>> Given userspace is always in that path (I think), without the
>>> tracepoints being enabled it will be one impressive guess to
>>> successfully make repair happen - you'll have to magically know
>>> what address will see a hit in the stored error records.
>>>
>>> Maybe that happens in some test case, but it doesn't feel real
>>> to me.  
>>
>> If you don't think that's possible then I'll drop the patch.
>>
> 
> It is possible if you injected the error and so know where it is.
> We may also get other paths by which people obtain that info such
> as anyone who is reporting via fabric management paths.  I just
> don't think it is a fix and perhaps we should wait for a user
> to come along who needs it.

Sure we can just wait.

      reply	other threads:[~2026-09-25 23:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-24 21:23 [PATCH] cxl/mbox: Store event records for EDAC repair regardless of tracing Dave Jiang
2026-09-25 22:44 ` Jonathan Cameron
2026-09-25 22:53   ` Dave Jiang
2026-09-25 23:50     ` Jonathan Cameron
2026-09-25 23:52       ` Dave Jiang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0f3b2ed5-d797-4914-b4bc-e0e83475ee42@intel.com \
    --to=dave.jiang@intel.com \
    --cc=alison.schofield@intel.com \
    --cc=dave@stgolabs.net \
    --cc=icheng@nvidia.com \
    --cc=jic23@kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=ming.li@zohomail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox