I am sorry for not being more clear.
In ACPI spec 2.6, the Table 15-317 has all the UEFI Memory Types and mapping to
ACPI address range types.
Here are the actual types that I referred to:
“Persistent”-> EfiPersistentMemory (14)“Reserved” -> Reserved type 15
Apparently, only my private kernel works as expected when dealing with Reserved
type (15) but cannot boot with any EfiPersistentMemory device. I did see a
EfiPersistentMemory device working with Ubuntu OS. I am suspecting it's my
environment issues (kconfig flags or others), I am curious about anyone has any
idea on how to debug this kind of "does not boot issue" or anyone has seen
EfiPersistentMemory like this?
ThanksCheng-mean
On Thursday, July 20, 2017 6:03 AM, Dan Williams <[email protected]>
wrote:
On Wed, Jul 19, 2017 at 5:04 PM, Soccer Liu <[email protected]> wrote:
> Hi:
> I am trying to debug an issue related to my private built kernel's (4.11
>from upstream with ACPI/NFIT/NVDIMM enabled) interaction with a persistent
>memory device's type.
> We have a way to emulate a software based NVDIMM device into a guest, which
> is running my private built kernel. When the host set this emulated NVDIMM
> device as Reserved type, I was able to see a pmem0 block device exposed and
> everything seems to function correctly.however, when it's exposed as a
> Persistent Memory type, the kernel does not boot and it has a black screen
> and no usefully logging could help root cause this.
> My questions are:
> 1. Is this a known issue for 4.11? 2. Is there any patches NIFT/NVDIMM
>beyond 4.11 that's needed to get Persistent Memory type supported? 3. In this
>case, is there anyway to debug this further?
When you say Persistent Memory Type, which type are you referring. The
spec compliant one is E820-type-7 or EFI- type-15. Linux also
understands E820-type-12 which went upstream before the official types
were defined.
E820-Type-12 is the problematic one, the others are equivalent to
Reserved (E820-Type-2).
All that said we have had functional support for all these types since
the 4.2 kernel, no kernel changes should be needed.
_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm
