4:07 a.m.
Hi
There is a deficiency in current e820.c handling where unknown new memory-chip
types come up as a BUSY resource when some other driver (like pmem) tries to
call request_mem_region_exclusive() on that resource. Even though, actually
there is nothing using it.
From inspecting the code and the history of e820.c it looks like a
BUG.
In any way this is a problem for the new type-12 NvDIMM memory chips that
are circulating around. (It is estimated that there are already 100ds of
thousands NvDIMM chips in active use)
The patches below first fixes the above problem for any future type
memory, so external drivers can access these mem chips.
I then also add the NvDIMM type-12 memory constant so it comes up
nice in dprints and at /proc/iomem
Just as before all these chips are very much usable with the pmem
driver. This lets us remove the hack for type-12 NvDIMMs that ignores
the return code from request_mem_region_exclusive() in pmem.c.
There is a 3rd patch just for reference to pmem.c which enables
pmem to work also on Old Kernels which do not include these 2
patches.
For all the pmem people. I maintain a tree with these patches
and latest pmem code (Also including DAX) here:
git://git.open-osd.org/pmem.git
[web-view:http://git.open-osd.org/gitweb.cgi?p=pmem.git;a=summary]
List of patches:
[PATCH 1/2] e820: Don't let unknown DIMM type come out BUSY
[RFC 2/2] e820: Add the NvDIMM Memory type (type-12)
These are for submission
[PATCH 3/3] pmem: Allow request_mem to fail (CONFIG_BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET)
Just for reference
Thanks
Boaz
4:13 a.m.
New subject: [Linux-nvdimm] [PATCH 1/2] e820: Don't let unknown DIMM type come out BUSY
There is something not very nice (Gentlemen nice) In current
e820.c code.
At Multiple place for example @ memblock_x86_fill(), it will
add the different memory resources *except the E820_RESERVED type*
Then at e820_reserve_resources() it will mark all !E820_RESERVED
as busy.
This is all fine when we have only the known types one of:
E820_RESERVED_KERN:
E820_RAM:
E820_ACPI:
E820_NVS:
E820_UNUSABLE:
E820_RESERVED:
But if the system encounters a brand new memory type it will
not add it to any memory list, But will proceed to mark it
BUSY. So now any other Driver in the system that does know
how to deal with this new type, is not able to call
request_mem_region_exclusive() on this new type because it is
hard coded BUSY even though nothing really uses it.
So make any unknown type behave like E820_RESERVED memory,
it will show up as available to first caller of
request_mem_region_exclusive().
I Also change the string representation of an unknown type
from "reserved" (So to not confuse with memmap "reserved"
region). And call it "reserved-unknown"
I wish I could return "reserved-type-X" But this is not possible
because one must return a constant, code-segment, string.
(NOTE: These unknown-types where called "reserved" in
/proc/iomem and in dmesg but behaved differently. What this
patch does is name them differently but let them behave
the same)
An example of such "UNKNOWN" type is the not Standard type-12
DDR3-NvDIMM which is used by multiple vendors for a while
now. (Estimated 100ds of thousands sold world wide)
A later patch adds type-12 to the list of "KNOWN", types.
Signed-off-by: Boaz Harrosh <boaz(a)plexistor.com>
---
arch/x86/kernel/e820.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 46201de..8cfd25f 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -907,7 +907,23 @@ static inline const char *e820_type_to_string(int e820_type)
case E820_ACPI: return "ACPI Tables";
case E820_NVS: return "ACPI Non-volatile Storage";
case E820_UNUSABLE: return "Unusable memory";
- default: return "reserved";
+ case E820_RESERVED: return "reserved";
+ default: return "reserved-unkown";
+ }
+}
+
+static bool _is_reserved_type(int e820_type)
+{
+ switch (e820_type) {
+ case E820_RESERVED_KERN:
+ case E820_RAM:
+ case E820_ACPI:
+ case E820_NVS:
+ case E820_UNUSABLE:
+ return false;
+ case E820_RESERVED:
+ default:
+ return true;
}
}
@@ -940,7 +956,7 @@ void __init e820_reserve_resources(void)
* pci device BAR resource and insert them later in
* pcibios_resource_survey()
*/
- if (e820.map[i].type != E820_RESERVED || res->start < (1ULL<<20)) {
+ if (!_is_reserved_type(e820.map[i].type) || res->start < (1ULL<<20)) {
res->flags |= IORESOURCE_BUSY;
insert_resource(&iomem_resource, res);
}
--
1.9.3
4:16 a.m.
New subject: [Linux-nvdimm] [RFC 2/2] e820: Add the NvDIMM Memory type (type-12)
There are multiple vendors of DDR3 NvDIMMs out in the market today.
At various stages of development/production. It is estimated that
there are already more the 100ds of thousands chips sold to
testers and sites.
All the vendors I know of, tagged these chips as type-12 memory.
[THIS IS A CALL FOR ALL NvDIMM Vendors if you have used other
then type-12 NvDIMM, please email me and I will add support
for it]
Now the ACPI comity, as far as I know, did not yet define a
standard type for NvDIMM. Also, as far as I know any NvDIMM
standard will be defined for DDR4. So DDR3 NvDIMM will continue
to be supported by the individual vendors.
I Wish and call the ACPI comity to Define that NvDIMM is type-12.
Also for DDR4
In this patch I name type-12 "NvDIMM-12", but if there
are positive responses I would like to just name it "NvDIMM",
For any kind of DDR-X.
Actually is there any reason why I should not submit the final
version as "NvDIMM" from the get go. Then if the ACPI defines
another new type-Y Memory we can name both types "NvDIMM", No?
Please comment
Signed-off-by: Boaz Harrosh <boaz(a)plexistor.com>
---
arch/x86/include/uapi/asm/e820.h | 2 +-
arch/x86/kernel/e820.c | 5 +++++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/uapi/asm/e820.h b/arch/x86/include/uapi/asm/e820.h
index d993e33..a0977e0 100644
--- a/arch/x86/include/uapi/asm/e820.h
+++ b/arch/x86/include/uapi/asm/e820.h
@@ -32,7 +32,7 @@
#define E820_ACPI 3
#define E820_NVS 4
#define E820_UNUSABLE 5
-
+#define E820_NvDIMM_12 12
/*
* reserved RAM used by kernel itself
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 8cfd25f..17f7496 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -149,6 +149,9 @@ static void __init e820_print_type(u32 type)
case E820_UNUSABLE:
printk(KERN_CONT "unusable");
break;
+ case E820_NvDIMM_12:
+ printk(KERN_CONT "NvDIMM-12");
+ break;
default:
printk(KERN_CONT "type %u", type);
break;
@@ -908,6 +911,7 @@ static inline const char *e820_type_to_string(int e820_type)
case E820_NVS: return "ACPI Non-volatile Storage";
case E820_UNUSABLE: return "Unusable memory";
case E820_RESERVED: return "reserved";
+ case E820_NvDIMM_12: return "NvDIMM-12";
default: return "reserved-unkown";
}
}
@@ -922,6 +926,7 @@ static bool _is_reserved_type(int e820_type)
case E820_UNUSABLE:
return false;
case E820_RESERVED:
+ case E820_NvDIMM_12:
default:
return true;
}
--
1.9.3
2:04 p.m.
New subject: [Linux-nvdimm] [RFC 2/2] e820: Add the NvDIMM Memory type (type-12)
On 02/16/2015 03:16 AM, Boaz Harrosh wrote:
There are multiple vendors of DDR3 NvDIMMs out in the market today.
At various stages of development/production. It is estimated that
there are already more the 100ds of thousands chips sold to
testers and sites.
All the vendors I know of, tagged these chips as type-12 memory.
[THIS IS A CALL FOR ALL NvDIMM Vendors if you have used other
then type-12 NvDIMM, please email me and I will add support
for it]
Now the ACPI comity, as far as I know, did not yet define a
standard type for NvDIMM. Also, as far as I know any NvDIMM
standard will be defined for DDR4. So DDR3 NvDIMM will continue
to be supported by the individual vendors.
I Wish and call the ACPI comity to Define that NvDIMM is type-12.
Also for DDR4
I really really hope you're kidding.
As a proud (?) owner of a couple of these devices, holy crap the type 12
enumeration mechanism is terrible. Let's see:
1. Some GRUB versions can't handle it. Yes, I got that fixed upstream.
But still.
2. UEFI can't handle it (no real e820 map means no type 12).
3. There's no way to enumerate the layout of the devices, whether
they're working, whether they're non-volatile, who made them, how to
talk to them (presumably via the not-yet-upstreamed i2c_imc driver, but
that's delayed due to a whole different clusterfs*k that I'm slowly
working on).
4. Whose bright idea was it to extend e820, for Pete's sake?
In this patch I name type-12 "NvDIMM-12", but if there
are positive responses I would like to just name it "NvDIMM",
For any kind of DDR-X.
How about "evil non-standard device that might be an NVDIMM"?
Actually is there any reason why I should not submit the final
version as "NvDIMM" from the get go. Then if the ACPI defines
another new type-Y Memory we can name both types "NvDIMM", No?
Please comment
I hope that ACPI *never* defines a new e820 memory type. Enumerate
these things for real.
To be clear, I have no real objection to fixing the "bug" in the memory
region code, but adding request_nonstandard_memory_region_exclusive()
might be a better idea.
--Andy
2:09 a.m.
New subject: [Linux-nvdimm] [RFC 2/2] e820: Add the NvDIMM Memory type (type-12)
On 02/16/2015 11:04 PM, Andy Lutomirski wrote:
On 02/16/2015 03:16 AM, Boaz Harrosh wrote:
>
<>
I really really hope you're kidding.
As a proud (?) owner of a couple of these devices, holy crap the type 12
enumeration mechanism is terrible. Let's see:
1. Some GRUB versions can't handle it. Yes, I got that fixed upstream.
But still.
2. UEFI can't handle it (no real e820 map means no type 12).
3. There's no way to enumerate the layout of the devices, whether
they're working, whether they're non-volatile, who made them, how to
talk to them (presumably via the not-yet-upstreamed i2c_imc driver, but
that's delayed due to a whole different clusterfs*k that I'm slowly
working on).
4. Whose bright idea was it to extend e820, for Pete's sake?
>
> In this patch I name type-12 "NvDIMM-12", but if there
> are positive responses I would like to just name it "NvDIMM",
> For any kind of DDR-X.
How about "evil non-standard device that might be an NVDIMM"?
OK Got it I'll change the name to something like "unkown-12"
or something like that.
>
> Actually is there any reason why I should not submit the final
> version as "NvDIMM" from the get go. Then if the ACPI defines
> another new type-Y Memory we can name both types "NvDIMM", No?
> Please comment
I hope that ACPI *never* defines a new e820 memory type. Enumerate
these things for real.
I kind of like it KISS style. Current code just works and there is nothing
new to write.
[I hope you guys take the lead and not completely re-invent the wheel all
over again]
But I hear you. If there is anything I can help with please feel free ...
To be clear, I have no real objection to fixing the "bug"
in the memory
region code, but adding request_nonstandard_memory_region_exclusive()
might be a better idea.
OK Funny ;-)
Please remember that even the VRAM on an PCIE card is
request_memory_region_exclusive(), or any kind of Vendore specific card
with "memory access". So off course a DDR bus device is
"memory_region"
(It is called /proc/iomem after all)
--Andy
Thanks
Boaz
12:04 p.m.
New subject: [Linux-nvdimm] [RFC 2/2] e820: Add the NvDIMM Memory type (type-12)
On Feb 17, 2015 1:09 AM, "Boaz Harrosh" <boaz(a)plexistor.com> wrote:
On 02/16/2015 11:04 PM, Andy Lutomirski wrote:
> On 02/16/2015 03:16 AM, Boaz Harrosh wrote:
>>
<>
>
> I really really hope you're kidding.
>
> As a proud (?) owner of a couple of these devices, holy crap the type 12
> enumeration mechanism is terrible. Let's see:
>
> 1. Some GRUB versions can't handle it. Yes, I got that fixed upstream.
> But still.
>
> 2. UEFI can't handle it (no real e820 map means no type 12).
>
> 3. There's no way to enumerate the layout of the devices, whether
> they're working, whether they're non-volatile, who made them, how to
> talk to them (presumably via the not-yet-upstreamed i2c_imc driver, but
> that's delayed due to a whole different clusterfs*k that I'm slowly
> working on).
>
> 4. Whose bright idea was it to extend e820, for Pete's sake?
>
>>
>> In this patch I name type-12 "NvDIMM-12", but if there
>> are positive responses I would like to just name it "NvDIMM",
>> For any kind of DDR-X.
>
> How about "evil non-standard device that might be an NVDIMM"?
>
OK Got it I'll change the name to something like "unkown-12"
or something like that.
>>
>> Actually is there any reason why I should not submit the final
>> version as "NvDIMM" from the get go. Then if the ACPI defines
>> another new type-Y Memory we can name both types "NvDIMM", No?
>> Please comment
>
> I hope that ACPI *never* defines a new e820 memory type. Enumerate
> these things for real.
>
I kind of like it KISS style. Current code just works and there is nothing
new to write.
[I hope you guys take the lead and not completely re-invent the wheel all
over again]
The trouble is that it doesn't really just work. My devices have a
string of NDA-required things one ought to do prior to touching the
e820-listed memory. And, if you have NVDIMMs from multiple vendors,
or even just one that doesn't match your BIOS, then I think you lose.
But I hear you. If there is anything I can help with please feel free ...
I think the scarier bits are being worked on. I'm not really in the loop.
> To be clear, I have no real objection to fixing the "bug" in the memory
> region code, but adding request_nonstandard_memory_region_exclusive()
> might be a better idea.
>
OK Funny ;-)
Please remember that even the VRAM on an PCIE card is
request_memory_region_exclusive(), or any kind of Vendore specific card
with "memory access". So off course a DDR bus device is
"memory_region"
(It is called /proc/iomem after all)
Fair enough.
--Andy
> --Andy
>
Thanks
Boaz
4:24 a.m.
New subject: [Linux-nvdimm] [PATCH 3/3] pmem: Allow request_mem to fail, (CONFIG_BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET)
With old Kernels there was a bug in x86 where any unknown
memory chip type would come up BUSY when calling
request_mem_region_exclusive().
So for pmem to work with old Kernels and real NvDIMM chips
we have a new Kconfig option CONFIG_BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET.
People have been running with hacked up pmem that will ignore
the return code from request_mem_region_exclusive. So here it is
official
Signed-off-by: Boaz Harrosh <boaz(a)plexistor.com>
---
drivers/block/Kconfig | 12 ++++++++++++
drivers/block/pmem.c | 11 +++++++----
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 3b3200f..10879b8 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -430,6 +430,18 @@ config BLK_DEV_PMEM_USE_PAGES
to other devices in the system, then you must say "Yes" here.
If unsure leave as Yes.
+config BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET
+ bool "Ignore the return code from request_mem_region_exclusive"
+ depends on BLK_DEV_PMEM
+ help
+ In Old Kernels type-12 Memory type which is used by NvDIMM
+ chips Comes out busy when calling request_mem_region_exclusive,
+ because of a bug.
+ If this option is set to "yes". The pmem will ignore the
+ failure, and continue as usual. If you have an old Kernel and
+ a real NvDIMM chip you must say yes here.
+ (Ignored if BLK_DEV_PMEM_USE_PAGES=y)
+
config CDROM_PKTCDVD
tristate "Packet writing on CD/DVD media"
depends on !UML
diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c
index 9eb7ffe..f84d033 100644
--- a/drivers/block/pmem.c
+++ b/drivers/block/pmem.c
@@ -197,10 +197,12 @@ int pmem_mapmem(struct pmem_device *pmem)
res_mem = request_mem_region_exclusive(pmem->phys_addr, pmem->size,
"pmem");
- if (!res_mem) {
+ if (unlikely(!res_mem)) {
pr_warn("pmem: request_mem_region_exclusive phys=0x%llx size=0x%zx
failed\n",
- pmem->phys_addr, pmem->size);
- return -EINVAL;
+ pmem->phys_addr, pmem->size);
+#ifndef CONFIG_BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET
+ return -EBUSY;
+#endif
}
pmem->virt_addr = ioremap_cache(pmem->phys_addr, pmem->size);
@@ -211,7 +213,8 @@ int pmem_mapmem(struct pmem_device *pmem)
return 0;
out_release:
- release_mem_region(pmem->phys_addr, pmem->size);
+ if (res_mem)
+ release_mem_region(pmem->phys_addr, pmem->size);
return err;
}
--
1.9.3
1:52 p.m.
New subject: [Linux-nvdimm] [PATCH 3/3] pmem: Allow request_mem to fail, (CONFIG_BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET)
On Mon, 2015-02-16 at 13:24 +0200, Boaz Harrosh wrote:
With old Kernels there was a bug in x86 where any unknown
memory chip type would come up BUSY when calling
request_mem_region_exclusive().
So for pmem to work with old Kernels and real NvDIMM chips
we have a new Kconfig option CONFIG_BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET.
People have been running with hacked up pmem that will ignore
the return code from request_mem_region_exclusive. So here it is
official
Signed-off-by: Boaz Harrosh <boaz(a)plexistor.com>
I'm confused - I thought that this behavior was fixed by patch 1/3?
With that patch this memory reservation should not fail, correct?
If so, why do we need this patch?
---
drivers/block/Kconfig | 12 ++++++++++++
drivers/block/pmem.c | 11 +++++++----
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 3b3200f..10879b8 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -430,6 +430,18 @@ config BLK_DEV_PMEM_USE_PAGES
to other devices in the system, then you must say "Yes" here.
If unsure leave as Yes.
+config BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET
+ bool "Ignore the return code from request_mem_region_exclusive"
+ depends on BLK_DEV_PMEM
+ help
+ In Old Kernels type-12 Memory type which is used by NvDIMM
+ chips Comes out busy when calling request_mem_region_exclusive,
+ because of a bug.
+ If this option is set to "yes". The pmem will ignore the
+ failure, and continue as usual. If you have an old Kernel and
+ a real NvDIMM chip you must say yes here.
+ (Ignored if BLK_DEV_PMEM_USE_PAGES=y)
+
config CDROM_PKTCDVD
tristate "Packet writing on CD/DVD media"
depends on !UML
diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c
index 9eb7ffe..f84d033 100644
--- a/drivers/block/pmem.c
+++ b/drivers/block/pmem.c
@@ -197,10 +197,12 @@ int pmem_mapmem(struct pmem_device *pmem)
res_mem = request_mem_region_exclusive(pmem->phys_addr, pmem->size,
"pmem");
- if (!res_mem) {
+ if (unlikely(!res_mem)) {
pr_warn("pmem: request_mem_region_exclusive phys=0x%llx size=0x%zx
failed\n",
- pmem->phys_addr, pmem->size);
- return -EINVAL;
+ pmem->phys_addr, pmem->size);
+#ifndef CONFIG_BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET
+ return -EBUSY;
+#endif
}
pmem->virt_addr = ioremap_cache(pmem->phys_addr, pmem->size);
@@ -211,7 +213,8 @@ int pmem_mapmem(struct pmem_device *pmem)
return 0;
out_release:
- release_mem_region(pmem->phys_addr, pmem->size);
+ if (res_mem)
+ release_mem_region(pmem->phys_addr, pmem->size);
return err;
}
2:58 a.m.
New subject: [Linux-nvdimm] [PATCH 3/3] pmem: Allow request_mem to fail, (CONFIG_BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET)
On 02/17/2015 10:52 PM, Ross Zwisler wrote:
On Mon, 2015-02-16 at 13:24 +0200, Boaz Harrosh wrote:
> With old Kernels there was a bug in x86 where any unknown
> memory chip type would come up BUSY when calling
> request_mem_region_exclusive().
>
> So for pmem to work with old Kernels and real NvDIMM chips
> we have a new Kconfig option CONFIG_BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET.
>
> People have been running with hacked up pmem that will ignore
> the return code from request_mem_region_exclusive. So here it is
> official
>
> Signed-off-by: Boaz Harrosh <boaz(a)plexistor.com>
Hi Ross, good morning
I'm confused - I thought that this behavior was fixed by patch
1/3?
With that patch this memory reservation should not fail, correct?
Yes, I have tested it extensively and PATCH-1/3 fixes this problem
for sure.
If so, why do we need this patch?
I put in this patch for people that do-not-want/cannot compile their
own Kernel but have a need for pmem.c regardless. I will not include
this patch in the final submitted Kernel. Given that patch-1 gets
accepted before the merge of pmem.
Lets say that patch-1 and patch-3 are either or. A tree
that has 1/3 does not need 3/3, a tree that does not have 1/3 needs
3/3.
<>
Thanks
Boaz
3:03 p.m.
On Mon, Feb 16, 2015 at 01:07:07PM +0200, Boaz Harrosh wrote:
In any way this is a problem for the new type-12 NvDIMM memory chips
that
are circulating around. (It is estimated that there are already 100ds of
thousands NvDIMM chips in active use)
Hang on. NV-DIMM chips don't know anyhing about E820 tables. They don't
have anything in them that says "I am type 12!". How they are reported
is up to the BIOS. Just because your BIOS vendor has chosen to report
tham as type 12 doesn't mean that any other BIOS vedor is going to have
done the same thing.
Fortunately, the BIOS people have all got together and decided what
they're going to do, and it's not type 12. Unfortunately, I think
I'm bound by various agreements to not say what they are going to do
until they do. But putting this temporary workaround in the kernel to
accomodate one BIOS vendor's unreleased experimental code seems like
entirely the wrong idea.
1:42 a.m.
On 02/17/2015 12:03 AM, Matthew Wilcox wrote:
On Mon, Feb 16, 2015 at 01:07:07PM +0200, Boaz Harrosh wrote:
> In any way this is a problem for the new type-12 NvDIMM memory chips that
> are circulating around. (It is estimated that there are already 100ds of
> thousands NvDIMM chips in active use)
Hang on. NV-DIMM chips don't know anyhing about E820 tables. They don't
have anything in them that says "I am type 12!". How they are reported
is up to the BIOS. Just because your BIOS vendor has chosen to report
tham as type 12 doesn't mean that any other BIOS vedor is going to have
done the same thing.
Fortunately, the BIOS people have all got together and decided what
they're going to do, and it's not type 12. Unfortunately, I think
I'm bound by various agreements to not say what they are going to do
until they do. But putting this temporary workaround in the kernel to
accomodate one BIOS vendor's unreleased experimental code seems like
entirely the wrong idea.
I had a feeling I'm entering an holy war ;-).
I hope you are OK with my first patch. That an unknown type need not
be reported busy, and behave same as "reserved"?
Then if we agree about PATCH-1, which is the actual fix.
Then the 2nd patch (hence the RFC btw) is nothing more than
a name.
I have an old BIOS that knows nothing of NvDIMM, actually a few
of them they all report 12.
The fact of the matter is that all the people I've talked with,
reported that different vendor chips, all came up type-12.
Perhaps type-12 just means "Unknown to current BIOS"
What is the name you suggest "type-12" "unknown-12".
Do you understand why they all come out 12 ?
Thanks
Boaz
11:15 a.m.
On Tue, Feb 17, 2015 at 12:42 AM, Boaz Harrosh <boaz(a)plexistor.com> wrote:
On 02/17/2015 12:03 AM, Matthew Wilcox wrote:
> On Mon, Feb 16, 2015 at 01:07:07PM +0200, Boaz Harrosh wrote:
>> In any way this is a problem for the new type-12 NvDIMM memory chips that
>> are circulating around. (It is estimated that there are already 100ds of
>> thousands NvDIMM chips in active use)
>
> Hang on. NV-DIMM chips don't know anyhing about E820 tables. They don't
> have anything in them that says "I am type 12!". How they are reported
> is up to the BIOS. Just because your BIOS vendor has chosen to report
> tham as type 12 doesn't mean that any other BIOS vedor is going to have
> done the same thing.
>
> Fortunately, the BIOS people have all got together and decided what
> they're going to do, and it's not type 12. Unfortunately, I think
> I'm bound by various agreements to not say what they are going to do
> until they do. But putting this temporary workaround in the kernel to
> accomodate one BIOS vendor's unreleased experimental code seems like
> entirely the wrong idea.
>
I had a feeling I'm entering an holy war ;-).
I hope you are OK with my first patch. That an unknown type need not
be reported busy, and behave same as "reserved"?
No, it seems the safe thing to do is prevent the kernel from accessing
any memory that it does not know the side-effects of accessing.
Then if we agree about PATCH-1, which is the actual fix.
Then the 2nd patch (hence the RFC btw) is nothing more than
a name.
I have an old BIOS that knows nothing of NvDIMM, actually a few
of them they all report 12.
The fact of the matter is that all the people I've talked with,
reported that different vendor chips, all came up type-12.
Perhaps type-12 just means "Unknown to current BIOS"
What is the name you suggest "type-12" "unknown-12".
Do you understand why they all come out 12 ?
In fact it was originally "type-6" until ACPI 5 claimed that number
for official use, so these platforms, with early proof-of-concept
nvdimm support, have already gone through one transition to a new
number. They need to do the same once an official number for nvdimm
support is published.
Put another way, these early platforms are already using out-of-tree
patches for nvdimm enabling. They can continue to do so, or switch to
standard methods when the standard is published.
2690
days inactive
2691
days old
11 comments
5 participants
participants (5)
-
Andy Lutomirski -
Boaz Harrosh -
Dan Williams -
Matthew Wilcox -
Ross Zwisler