On Fri, Mar 30, 2018 at 8:04 AM, Kani, Toshi <toshi.kani@xxxxxxx> wrote: > On Thu, 2018-03-29 at 15:37 -0700, Dave Jiang wrote: >> The following series implements support for parsing of the BERT records >> and adding the error memory ranges to nvdimm badblocks in order for the >> kernel to avoid prevent the kernel from accessing those areas. And with >> the addition of this support, we can surface the nd regions instead of waiting >> for ARS to complete. So the ARS handling is reworked to run in the >> background and not block nd region registration. > > Hi Dave, > > I agree on the problem, and adding an ability to obtain pmem badblocks > records at boot-time without waiting for a new ARS scan to complete is a > good option for users. > > However, I do not think using the BERT table is a good approach. This > requires FW to report pmem badblocks records with a new interface in > addition to ARS records, which FW already implements for pmem. ACPI 6.2 > defines Start ARS with Flags Bit[1] set to report badblocks record > without starting a new ARS scan. We set this bit after receiving a 0x81 > notification at this point. > > Can we use ARS with Flags bit[1] set at boot-time so that both OS and FW > can use the same ARS implementation? You have a point. The other benefit I see to this policy is that it hopefully convinces BIOS implementations to not run ARS at boot and leave it to the OS to manage it in the background. If the platform has any critical errors to report, i.e. ones that triggered a system reset, then it should be able to report them in the flag-bit1 case. This also lets the implementation be completely self contained to the nfit driver, and not grow any BERT entanglements that may or may not be valid for the persistent memory case. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
