[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251014135206.GA361227@yaz-khff2.amd.com>
Date: Tue, 14 Oct 2025 09:52:06 -0400
From: Yazen Ghannam <yazen.ghannam@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: Avadhut Naik <avadhut.naik@....com>, linux-edac@...r.kernel.org,
john.allen@....com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/2] Incorporate DRAM address in EDAC messages
On Tue, Oct 14, 2025 at 12:00:19AM +0200, Borislav Petkov wrote:
> On Mon, Oct 13, 2025 at 07:34:47PM +0000, Avadhut Naik wrote:
> > Currently, the amd64_edac module only provides UMC normalized and system
> > physical address when a DRAM ECC error occurs. DRAM Address is neither
> > logged nor exported through tracepoint.
> >
> > Modern AMD SOCs provide UEFI PRM module that implements various address
> > translation PRM handlers. These PRM handlers can be leveraged to convert
> > UMC normalized address into DRAM address at runtime on occurrence of a
> > DRAM ECC error. This translated DRAM address can then be logged and
> > exported through tracepoints.
>
> And?
>
> I read all three commit messages to figure out *why* those DRAM addresses want
> to be logged. But it seems they don't want to be logged. Because there's not
> a single reason why they should be, AFAICT. Without a proper justification,
> this looks like a bunch of unnecessary code to me...
>
Good point. I overlooked this myself.
The "DRAM address" helps memory vendors analyze failures. System
builders want to collect this data and pass it along to the memory
vendors. The DRAM address is not contained in architectural data like
MCA info, and getting the address from MCA requires using additional
system-specific hardware info. It's much more reliable to get the DRAM
address from the system with the error rather than try to post-process
it later.
Thanks,
Yazen
Powered by blists - more mailing lists