Hi I would like to know if you encountered such a problem.
We are accessing the nvram as memory from withing the kernel. By mapping dax device and reading its mapping we can know the physical address of the nvram. As a result we can access this address range in the kernel by calling phys_to_virt. This is working in most case but we saw some issue that after reboot, when trying to read the info saved on the nvram before the power off, one kernel thread was able to read from this range but another kernel thread got page fault. This is not recreated very easily and we need run many reboot sequences to get this failure again. Are you aware of any mapping issues of nvram to kernel space? Thanks for any suggestions you might have. BR Oren On 31 December 2017 at 10:23, Yigal Korman <yi...@plexistor.com> wrote: > You can try to force a legacy pmem device with memmap=XX!YY kernel > parameter. > > On Thu, Dec 28, 2017 at 8:16 PM, Dan Williams <dan.j.willi...@intel.com> > wrote: > >> Type-7 only tells the kernel to reserve the memory range. NFIT carves that >> reservation into pmem devices. Type-12 skips the reservation and creates a >> pmem device directly. There is no workaround if the platform only has a >> BIOS that produces a type-12 range. >> >> >> On Thursday, December 28, 2017, Oren Berman <o...@lightbitslabs.com> >> wrote: >> >> > Thanks Dan. >> > I understand the shortcomings of using legacy mode but currently my >> problem >> > is that TYPE 12 is detected and I can use dax even in legacy mode but >> for >> > some reason type 7 is not. Is there a way to force it be treated as >> legacy >> > as well. >> > The reason I am asking is that I am not sure I can change my bios and I >> > know at least that type 12 NVDIMM is working for me. >> > >> > BR >> > Oren >> > >> > >> > >> > On 28 December 2017 at 11:14, Dan Williams <dan.j.willi...@intel.com> >> > wrote: >> > >> > > [sent from my phone, forgive formatting] >> > > >> > > Your BIOS would need to put SPA range entries in the ACPI NFIT. The >> > > problem with legacy pmem ranges in the e820 table is that it omits >> > critical >> > > details like battery status and whether the platform supports flushing >> > > memory controller buffers at power loss (ADR). >> > > >> > > The NFIT can also reliably communicate NUMA information for NVDIMMs >> that >> > > e820 does not. >> > > >> > > On Wednesday, December 27, 2017, Oren Berman <o...@lightbitslabs.com> >> > > wrote: >> > > >> > >> Hi >> > >> >> > >> I have a question regrading NVDIMM detection. >> > >> >> > >> When we are working with NVDIMM of type 12 it is detected by the >> linux >> > in >> > >> legacy mode and we can >> > >> accesses it as pmem or dax device. we have an e820 bios. >> > >> >> > >> When we are using a type 7 NVDIMM it is reported by the linux as >> > >> persistence type 7 memory but there is no pmem or dax device created. >> > >> Linux Kernel identifies this memory in the e820 table but it does not >> > >> trigger nvdimm probe for it. >> > >> Do you know what could be the cause? Is their a workaround for that? >> > >> Can it still be treated as legacy mode so we can access it through >> > >> pmem/dax >> > >> device? >> > >> >> > >> BR >> > >> Oren Berman >> > >> >> > >> On 22 October 2017 at 16:52, Dan Williams <dan.j.willi...@intel.com> >> > >> wrote: >> > >> >> > >> > On Sun, Oct 22, 2017 at 4:33 AM, Oren Berman < >> o...@lightbitslabs.com> >> > >> > wrote: >> > >> > > Hi Ross >> > >> > > >> > >> > > Thanks for the speedy reply. I am also adding the public list to >> > this >> > >> > > thread as you suggested. >> > >> > > >> > >> > > We have tried to dump the SPA table and this is what we get: >> > >> > > >> > >> > > /* >> > >> > > * Intel ACPI Component Architecture >> > >> > > * AML/ASL+ Disassembler version 20160108-64 >> > >> > > * Copyright (c) 2000 - 2016 Intel Corporation >> > >> > > * >> > >> > > * Disassembly of NFIT, Sun Oct 22 10:46:19 2017 >> > >> > > * >> > >> > > * ACPI Data Table [NFIT] >> > >> > > * >> > >> > > * Format: [HexOffset DecimalOffset ByteLength] FieldName : >> > >> FieldValue >> > >> > > */ >> > >> > > >> > >> > > [000h 0000 4] Signature : "NFIT" [NVDIMM >> > >> Firmware >> > >> > > Interface Table] >> > >> > > [004h 0004 4] Table Length : 00000028 >> > >> > > [008h 0008 1] Revision : 01 >> > >> > > [009h 0009 1] Checksum : B2 >> > >> > > [00Ah 0010 6] Oem ID : "SUPERM" >> > >> > > [010h 0016 8] Oem Table ID : "SMCI--MB" >> > >> > > [018h 0024 4] Oem Revision : 00000001 >> > >> > > [01Ch 0028 4] Asl Compiler ID : " " >> > >> > > [020h 0032 4] Asl Compiler Revision : 00000001 >> > >> > > >> > >> > > [024h 0036 4] Reserved : 00000000 >> > >> > > >> > >> > > Raw Table Data: Length 40 (0x28) >> > >> > > >> > >> > > 0000: 4E 46 49 54 28 00 00 00 01 B2 53 55 50 45 52 4D // >> > >> > NFIT(.....SUPERM >> > >> > > 0010: 53 4D 43 49 2D 2D 4D 42 01 00 00 00 01 00 00 00 // >> > >> > SMCI--MB........ >> > >> > > 0020: 01 00 00 00 00 00 00 00 >> > >> > > >> > >> > > As you can see the memory region info is missing. >> > >> > > >> > >> > > This specific check was done on a supermicro server. >> > >> > > We also performed a bios update but the results were the same. >> > >> > > >> > >> > > As said before ,the pmem devices are detected correctly and we >> > >> verified >> > >> > > that they correspond to different numa nodes using the PCM >> > >> > utility.However, >> > >> > > linux still reports both pmem devices to be on the same numa - >> Numa >> > >> 0. >> > >> > > >> > >> > > If this information is missing, why pmem devices and address >> ranges >> > >> are >> > >> > > still detected correctly? >> > >> > >> > >> > I suspect your BIOS might be using E820-type-12 to describe the >> pmem >> > >> > ranges which is not compliant with the ACPI specification and would >> > >> > need a BIOS change. >> > >> > >> > >> > > Is there another table that we need to check? >> > >> > >> > >> > You can dump /proc/iomem. If it shows "Persistent Memory (legacy)" >> > >> > then the BIOS is using the E820-type-12 description scheme which >> does >> > >> > not include NUMA information. >> > >> > >> > >> _______________________________________________ >> > >> Linux-nvdimm mailing list >> > >> Linux-nvdimm@lists.01.org >> > >> https://lists.01.org/mailman/listinfo/linux-nvdimm >> > >> >> > > >> > _______________________________________________ >> > Linux-nvdimm mailing list >> > Linux-nvdimm@lists.01.org >> > https://lists.01.org/mailman/listinfo/linux-nvdimm >> > >> _______________________________________________ >> Linux-nvdimm mailing list >> Linux-nvdimm@lists.01.org >> https://lists.01.org/mailman/listinfo/linux-nvdimm >> > > _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
