[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <62d0c0947c3e6_1643dc2944a@dwillia2-xfh.jf.intel.com.notmuch>
Date: Thu, 14 Jul 2022 18:19:16 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Jane Chu <jane.chu@...cle.com>,
Dan Williams <dan.j.williams@...el.com>,
"hch@...radead.org" <hch@...radead.org>,
"vishal.l.verma@...el.com" <vishal.l.verma@...el.com>,
"dave.jiang@...el.com" <dave.jiang@...el.com>,
"ira.weiny@...el.com" <ira.weiny@...el.com>,
"nvdimm@...ts.linux.dev" <nvdimm@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] acpi/nfit: badrange report spill over to clean range
Jane Chu wrote:
> I meant to say there would be 8 calls to the nfit_handle_mce() callback,
> one call for each poison with accurate address.
>
> Also, short ARS would find 2 poisons.
>
> I attached the console output, my annotation is prefixed with "<==".
[29078.634817] {4}[Hardware Error]: physical_address: 0x00000040a0602600 <== 2nd poison @ 0x600
[29078.642200] {4}[Hardware Error]: physical_address_mask: 0xffffffffffffff00
Why is nfit_handle_mce() seeing a 4K address mask when the CPER record
is seeing a 256-byte address mask?
Sigh, is this "firmware-first" causing the kernel to get bad information
via the native mechanisms?
I would expect that if this test was truly worried about minimizing BIOS
latency it would disable firmware-first error reporting. I wonder if
that fixes the observed problem?
Powered by blists - more mailing lists