Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On 02/22/2015 07:05 PM, Boaz Harrosh wrote: > On 02/22/2015 06:27 PM, Christoph Hellwig wrote: <> >> I won't be back to my nvdimm enabled hardware until after LSF/MM, >> so any work from me in this area will have to wait a bit. >> <> BTW: I have an out-of-tree patch that enables me to just emulate an NvDIMM inside a VM, so I can develop at the comfort of my LP. You can find it at my pmem tree. All it does is adds a new type of memmap=. So if you specify memmap=2G\&4G on Kernel command-line the code will insert a type-12 memory to the list, instead of "reserved" region when a "$" is parsed. >From here on that region will look exactly like an DDR3-NvDIMM with supporting BIOS to the system, safe the persistence of course. (Actually there is a trick to force the KVM-Host to reserve that memory across VM boots, to emulate persistence) Cheers Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On 02/22/2015 06:27 PM, Christoph Hellwig wrote: > On Thu, Feb 19, 2015 at 11:25:37AM +0200, Boaz Harrosh wrote: >> I do not see why you need the nvdimm_type= kernel option at all. >> >> I have here a script that auto detects any NvDIMM. It works with all >> the chips that I have access to. And Also it has support for if you have >> memmap=sss\$aaa. >> For all these detected regions it will load a pmem device. >> >> It is easy to filter for any type of memory you want. What >> will the (annoying) kernel option give you? >> >> OK I might be jumping the guns, send the patch and I'll look >> at it. > > The kernel option means we can autodetect the nvdimms in kernel space > with just that option set, no need for needing userspace setup. > Do you mean that pmem is: - Loaded without any parameters. - A new API is defined for enumerating NvDIMMs. pmem uses that for creating new devices. - e820 registers such devices according to special type passed on Kernel command-line. (That could be a Kconfig as well you know, I hate Kernel command-line) (Similar to what very old prd.c did only not hacking the e820 lists directly) > How does your script / patch work? > Easy just parses /proc/iomem + looks at Kernel command line. It has support not only for type-12 memory but also for "reserved" regions, made by memmap=sss$aaa stated on command line. And/or also an /etc/pmem.cfg list of regions. So you can go automatic or manual or a mix of both (And slice a region for xfstests scratch device). In any case it helps to have my patches, but also old Kernels are supported with the BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET. On old Kernels they are all "reserved" regions, no unknown-12 type. Once a list of regions or split-regions is established pmem is loaded with that list. > I won't be back to my nvdimm enabled hardware until after LSF/MM, > so any work from me in this area will have to wait a bit. > Have a good time. Will you guys have a talk about pmem ? If yes I would love it if you guys can talk about the use-of-pages-with-pmem. Please tell me I can write a looong argument about it. Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On Thu, Feb 19, 2015 at 11:25:37AM +0200, Boaz Harrosh wrote: > I do not see why you need the nvdimm_type= kernel option at all. > > I have here a script that auto detects any NvDIMM. It works with all > the chips that I have access to. And Also it has support for if you have > memmap=sss\$aaa. > For all these detected regions it will load a pmem device. > > It is easy to filter for any type of memory you want. What > will the (annoying) kernel option give you? > > OK I might be jumping the guns, send the patch and I'll look > at it. The kernel option means we can autodetect the nvdimms in kernel space with just that option set, no need for needing userspace setup. How does your script / patch work? I won't be back to my nvdimm enabled hardware until after LSF/MM, so any work from me in this area will have to wait a bit. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On 02/22/2015 07:05 PM, Boaz Harrosh wrote: On 02/22/2015 06:27 PM, Christoph Hellwig wrote: I won't be back to my nvdimm enabled hardware until after LSF/MM, so any work from me in this area will have to wait a bit. BTW: I have an out-of-tree patch that enables me to just emulate an NvDIMM inside a VM, so I can develop at the comfort of my LP. You can find it at my pmem tree. All it does is adds a new type of memmap=. So if you specify memmap=2G\4G on Kernel command-line the code will insert a type-12 memory to the list, instead of reserved region when a $ is parsed. From here on that region will look exactly like an DDR3-NvDIMM with supporting BIOS to the system, safe the persistence of course. (Actually there is a trick to force the KVM-Host to reserve that memory across VM boots, to emulate persistence) Cheers Boaz -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On Thu, Feb 19, 2015 at 11:25:37AM +0200, Boaz Harrosh wrote: I do not see why you need the nvdimm_type= kernel option at all. I have here a script that auto detects any NvDIMM. It works with all the chips that I have access to. And Also it has support for if you have memmap=sss\$aaa. For all these detected regions it will load a pmem device. It is easy to filter for any type of memory you want. What will the (annoying) kernel option give you? OK I might be jumping the guns, send the patch and I'll look at it. The kernel option means we can autodetect the nvdimms in kernel space with just that option set, no need for needing userspace setup. How does your script / patch work? I won't be back to my nvdimm enabled hardware until after LSF/MM, so any work from me in this area will have to wait a bit. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On 02/22/2015 06:27 PM, Christoph Hellwig wrote: On Thu, Feb 19, 2015 at 11:25:37AM +0200, Boaz Harrosh wrote: I do not see why you need the nvdimm_type= kernel option at all. I have here a script that auto detects any NvDIMM. It works with all the chips that I have access to. And Also it has support for if you have memmap=sss\$aaa. For all these detected regions it will load a pmem device. It is easy to filter for any type of memory you want. What will the (annoying) kernel option give you? OK I might be jumping the guns, send the patch and I'll look at it. The kernel option means we can autodetect the nvdimms in kernel space with just that option set, no need for needing userspace setup. Do you mean that pmem is: - Loaded without any parameters. - A new API is defined for enumerating NvDIMMs. pmem uses that for creating new devices. - e820 registers such devices according to special type passed on Kernel command-line. (That could be a Kconfig as well you know, I hate Kernel command-line) (Similar to what very old prd.c did only not hacking the e820 lists directly) How does your script / patch work? Easy just parses /proc/iomem + looks at Kernel command line. It has support not only for type-12 memory but also for reserved regions, made by memmap=sss$aaa stated on command line. And/or also an /etc/pmem.cfg list of regions. So you can go automatic or manual or a mix of both (And slice a region for xfstests scratch device). In any case it helps to have my patches, but also old Kernels are supported with the BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET. On old Kernels they are all reserved regions, no unknown-12 type. Once a list of regions or split-regions is established pmem is loaded with that list. I won't be back to my nvdimm enabled hardware until after LSF/MM, so any work from me in this area will have to wait a bit. Have a good time. Will you guys have a talk about pmem ? If yes I would love it if you guys can talk about the use-of-pages-with-pmem. Please tell me I can write a looong argument about it. Thanks Boaz -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On 02/19/2015 12:31 PM, Ingo Molnar wrote: <> >> I will submit a new version of my patch-1 with the >> pr_warn. >> >> Or did you already apply my patch-1 and you want one on >> top? What is the URL of your tree please? > > New patch please, and please also Cc: everyone who > expressed interest in the thread and who wasn't Cc:-ed to > the original patch. > > Thanks, > > Ingo > Thank you Ingo I will submit V2 of my patch-1, with the changes you requested And also add a new patch that adds the "warning if such a region is then claimed" Because this will need to go to a generic part of the Kernel. working on it now Thanks again Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
* Boaz Harrosh wrote: > Do you require another redundant message who's purpose is to scare > people off, like: > > e820: WARN [mem 0x0001-0x00017fff] is unknown type > 12 > > Sure I'll add it That message looks useful (and not very scary), and also emit a warning if such a region is then claimed by a driver. This puts some pressure on both the firmware and the kernel side to get their act together, without holding functionality hostage. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
* Boaz Harrosh wrote: > On 02/19/2015 12:01 PM, Ingo Molnar wrote: > > > > * Dan Williams wrote: > > > >> On Wed, Feb 18, 2015 at 4:47 PM, Christoph Hellwig > >> wrote: > >>> On Wed, Feb 18, 2015 at 10:15:32AM -0800, Dan Williams wrote: > 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. > >>> > >>> Not supporting hardware that is widely avaiable (I have > >>> some, too) is not very user friendly. > >> > >> Yes, as I agreed with Ingo, allowing a driver to assume > >> control of an unknown memory type with a warning or a > >> kernel taint seems fine. > > > > If someone cooks up such a patch I can apply it. > > > > Thanks, > > > > Ingo > > > > I will submit a new version of my patch-1 with the > pr_warn. > > Or did you already apply my patch-1 and you want one on > top? What is the URL of your tree please? New patch please, and please also Cc: everyone who expressed interest in the thread and who wasn't Cc:-ed to the original patch. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On 02/19/2015 12:01 PM, Ingo Molnar wrote: > > * Dan Williams wrote: > >> On Wed, Feb 18, 2015 at 4:47 PM, Christoph Hellwig >> wrote: >>> On Wed, Feb 18, 2015 at 10:15:32AM -0800, Dan Williams wrote: 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. >>> >>> Not supporting hardware that is widely avaiable (I have >>> some, too) is not very user friendly. >> >> Yes, as I agreed with Ingo, allowing a driver to assume >> control of an unknown memory type with a warning or a >> kernel taint seems fine. > > If someone cooks up such a patch I can apply it. > > Thanks, > > Ingo > I will submit a new version of my patch-1 with the pr_warn. Or did you already apply my patch-1 and you want one on top? What is the URL of your tree please? Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On 02/18/2015 09:35 PM, Dan Williams wrote: > On Wed, Feb 18, 2015 at 11:27 AM, Ingo Molnar wrote: >> <> >>> >>> 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. >> <> The Kernel does not do any such access. Reading the code the "busy" state of the unknown type looks like an accident to me. The code just assumes all types are known. And did a negative check. Consider a memory-region that sits on a PCIE slot. The BUS does not know anything about that BAR, it just exposes that information up the stack so a driver can positively identify its device and drive it. Same here. e820 is just a description of what sits on the DDR I^2C bus as read by the BIOS (or other means). The actual driver of these is for example the add_memory() call. Well sure unknown-types are not added to any active use. Parallel to what you are saying is that we band any PCI-ID that does not have a registered device-id, the card will be enumerated but drivers will receive "already taken" even though no one is using it. If you really believe in what you are saying then please move away from the "busy" bit. "busy" bit means "taken". Have a new bit saying. "no one told me about this device" >> Well, except when the kernel does know how to access >> it: when an nvdimm driver knows about its own memory >> region and knows how to handle it, right? > <> But ... if a user is blessed/haunted with such firmware, why not let new types fall back to 'reserved', which is a reasonable default that still allows sufficiently aware Linux drivers to work, right? >>> I want to emphasize here. After my patch the new type is distinctly differentiated from the regular "reserved" type so any knowledgeable driver can easily distinguish it from a regular "reserved" region. Only that when such driver wants to register its use of that region it does not receive a phony busy. [And Proceed to use that region by ignoring the phony busy] <> >> >> Well, we could emit a warning (or taint the kernel), to >> keep the user informed that there's a version mismatch >> between kernel and firmware - but otherwise still allow >> informed drivers to register that region? > > Sounds good to me. > There is already a distinct message both at dmesg bring up: user: [mem 0x0001-0x00017fff] type 12 And at /proc/iomem 1-1 : reserved-unknown I would love to make this: 1-1 : unknown-12 But it will need a bit of code to maintain such strings So the information for any one that wants to look for it is there. Do you require another redundant message who's purpose is to scare people off, like: e820: WARN [mem 0x0001-0x00017fff] is unknown type 12 Sure I'll add it Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
* Dan Williams wrote: > On Wed, Feb 18, 2015 at 4:47 PM, Christoph Hellwig wrote: > > On Wed, Feb 18, 2015 at 10:15:32AM -0800, Dan Williams wrote: > >> 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. > > > > Not supporting hardware that is widely avaiable (I have > > some, too) is not very user friendly. > > Yes, as I agreed with Ingo, allowing a driver to assume > control of an unknown memory type with a warning or a > kernel taint seems fine. If someone cooks up such a patch I can apply it. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On 02/19/2015 02:47 AM, Christoph Hellwig wrote: > On Wed, Feb 18, 2015 at 10:15:32AM -0800, Dan Williams wrote: >> 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. > > Not supporting hardware that is widely avaiable (I have some, too) > is not very user friendly. > > I'll submit a patch allowing a nvdimm_type= kernel option that allows > to detect them, but will do nothing by default. The code needed is very > small and it would be very useful for all kinds of projects. > I do not see why you need the nvdimm_type= kernel option at all. I have here a script that auto detects any NvDIMM. It works with all the chips that I have access to. And Also it has support for if you have memmap=sss\$aaa. For all these detected regions it will load a pmem device. It is easy to filter for any type of memory you want. What will the (annoying) kernel option give you? OK I might be jumping the guns, send the patch and I'll look at it. Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On 02/19/2015 02:47 AM, Christoph Hellwig wrote: On Wed, Feb 18, 2015 at 10:15:32AM -0800, Dan Williams wrote: 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. Not supporting hardware that is widely avaiable (I have some, too) is not very user friendly. I'll submit a patch allowing a nvdimm_type= kernel option that allows to detect them, but will do nothing by default. The code needed is very small and it would be very useful for all kinds of projects. I do not see why you need the nvdimm_type= kernel option at all. I have here a script that auto detects any NvDIMM. It works with all the chips that I have access to. And Also it has support for if you have memmap=sss\$aaa. For all these detected regions it will load a pmem device. It is easy to filter for any type of memory you want. What will the (annoying) kernel option give you? OK I might be jumping the guns, send the patch and I'll look at it. Thanks Boaz -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
* Dan Williams dan.j.willi...@intel.com wrote: On Wed, Feb 18, 2015 at 4:47 PM, Christoph Hellwig h...@infradead.org wrote: On Wed, Feb 18, 2015 at 10:15:32AM -0800, Dan Williams wrote: 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. Not supporting hardware that is widely avaiable (I have some, too) is not very user friendly. Yes, as I agreed with Ingo, allowing a driver to assume control of an unknown memory type with a warning or a kernel taint seems fine. If someone cooks up such a patch I can apply it. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On 02/19/2015 12:01 PM, Ingo Molnar wrote: * Dan Williams dan.j.willi...@intel.com wrote: On Wed, Feb 18, 2015 at 4:47 PM, Christoph Hellwig h...@infradead.org wrote: On Wed, Feb 18, 2015 at 10:15:32AM -0800, Dan Williams wrote: 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. Not supporting hardware that is widely avaiable (I have some, too) is not very user friendly. Yes, as I agreed with Ingo, allowing a driver to assume control of an unknown memory type with a warning or a kernel taint seems fine. If someone cooks up such a patch I can apply it. Thanks, Ingo I will submit a new version of my patch-1 with the pr_warn. Or did you already apply my patch-1 and you want one on top? What is the URL of your tree please? Thanks Boaz -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On 02/18/2015 09:35 PM, Dan Williams wrote: On Wed, Feb 18, 2015 at 11:27 AM, Ingo Molnar mi...@kernel.org wrote: 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. The Kernel does not do any such access. Reading the code the busy state of the unknown type looks like an accident to me. The code just assumes all types are known. And did a negative check. Consider a memory-region that sits on a PCIE slot. The BUS does not know anything about that BAR, it just exposes that information up the stack so a driver can positively identify its device and drive it. Same here. e820 is just a description of what sits on the DDR I^2C bus as read by the BIOS (or other means). The actual driver of these is for example the add_memory() call. Well sure unknown-types are not added to any active use. Parallel to what you are saying is that we band any PCI-ID that does not have a registered device-id, the card will be enumerated but drivers will receive already taken even though no one is using it. If you really believe in what you are saying then please move away from the busy bit. busy bit means taken. Have a new bit saying. no one told me about this device Well, except when the kernel does know how to access it: when an nvdimm driver knows about its own memory region and knows how to handle it, right? But ... if a user is blessed/haunted with such firmware, why not let new types fall back to 'reserved', which is a reasonable default that still allows sufficiently aware Linux drivers to work, right? I want to emphasize here. After my patch the new type is distinctly differentiated from the regular reserved type so any knowledgeable driver can easily distinguish it from a regular reserved region. Only that when such driver wants to register its use of that region it does not receive a phony busy. [And Proceed to use that region by ignoring the phony busy] Well, we could emit a warning (or taint the kernel), to keep the user informed that there's a version mismatch between kernel and firmware - but otherwise still allow informed drivers to register that region? Sounds good to me. There is already a distinct message both at dmesg bring up: user: [mem 0x0001-0x00017fff] type 12 And at /proc/iomem 1-1 : reserved-unknown I would love to make this: 1-1 : unknown-12 But it will need a bit of code to maintain such strings So the information for any one that wants to look for it is there. Do you require another redundant message who's purpose is to scare people off, like: e820: WARN [mem 0x0001-0x00017fff] is unknown type 12 Sure I'll add it Thanks Boaz -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
* Boaz Harrosh b...@plexistor.com wrote: Do you require another redundant message who's purpose is to scare people off, like: e820: WARN [mem 0x0001-0x00017fff] is unknown type 12 Sure I'll add it That message looks useful (and not very scary), and also emit a warning if such a region is then claimed by a driver. This puts some pressure on both the firmware and the kernel side to get their act together, without holding functionality hostage. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
* Boaz Harrosh b...@plexistor.com wrote: On 02/19/2015 12:01 PM, Ingo Molnar wrote: * Dan Williams dan.j.willi...@intel.com wrote: On Wed, Feb 18, 2015 at 4:47 PM, Christoph Hellwig h...@infradead.org wrote: On Wed, Feb 18, 2015 at 10:15:32AM -0800, Dan Williams wrote: 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. Not supporting hardware that is widely avaiable (I have some, too) is not very user friendly. Yes, as I agreed with Ingo, allowing a driver to assume control of an unknown memory type with a warning or a kernel taint seems fine. If someone cooks up such a patch I can apply it. Thanks, Ingo I will submit a new version of my patch-1 with the pr_warn. Or did you already apply my patch-1 and you want one on top? What is the URL of your tree please? New patch please, and please also Cc: everyone who expressed interest in the thread and who wasn't Cc:-ed to the original patch. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On 02/19/2015 12:31 PM, Ingo Molnar wrote: I will submit a new version of my patch-1 with the pr_warn. Or did you already apply my patch-1 and you want one on top? What is the URL of your tree please? New patch please, and please also Cc: everyone who expressed interest in the thread and who wasn't Cc:-ed to the original patch. Thanks, Ingo Thank you Ingo I will submit V2 of my patch-1, with the changes you requested And also add a new patch that adds the warning if such a region is then claimed Because this will need to go to a generic part of the Kernel. working on it now Thanks again Boaz -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On Wed, Feb 18, 2015 at 4:47 PM, Christoph Hellwig wrote: > On Wed, Feb 18, 2015 at 10:15:32AM -0800, Dan Williams wrote: >> 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. > > Not supporting hardware that is widely avaiable (I have some, too) > is not very user friendly. Yes, as I agreed with Ingo, allowing a driver to assume control of an unknown memory type with a warning or a kernel taint seems fine. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On Wed, Feb 18, 2015 at 10:15:32AM -0800, Dan Williams wrote: > 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. Not supporting hardware that is widely avaiable (I have some, too) is not very user friendly. I'll submit a patch allowing a nvdimm_type= kernel option that allows to detect them, but will do nothing by default. The code needed is very small and it would be very useful for all kinds of projects. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On Wed, Feb 18, 2015 at 11:27 AM, Ingo Molnar wrote: > > * Dan Williams wrote: > >> On Wed, Feb 18, 2015 at 10:53 AM, Ingo Molnar wrote: >> > >> > * Dan Williams wrote: >> > >> >> On Wed, Feb 18, 2015 at 10:30 AM, Ingo Molnar wrote: >> >> > >> >> > * Dan Williams wrote: >> >> > >> >> >> On Tue, Feb 17, 2015 at 12:42 AM, Boaz Harrosh >> >> >> 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. >> >> > >> >> > Well, except when the kernel does know how to access >> >> > it: when an nvdimm driver knows about its own memory >> >> > region and knows how to handle it, right? >> >> >> >> Yes, except that "type-12" is something picked out of the >> >> air that may be invalidated by a future spec change. >> >> >> >> If firmware wants any driver to handle a memory range it >> >> can already use E820_RESERVED. The only reason a >> >> new-type was picked in these early implementations was >> >> for experiments around reserving nvdimm memory for driver >> >> use, but also extending it to be covered with struct page >> >> mappings. Outside of that there is no real driving >> >> reason for the new type. >> > >> > But ... if a user is blessed/haunted with such firmware, >> > why not let new types fall back to 'reserved', which is a >> > reasonable default that still allows sufficiently aware >> > Linux drivers to work, right? >> >> True. >> >> > >> >> > So is there any practical reason to mark the memory >> >> > resource as busy in that case, instead of just adding >> >> > it to the reserved list by default and allowing >> >> > properly informed drivers to (exclusively) request it? >> >> >> >> I'm not sure we want firmware to repeat this confusion >> >> going forward. Why support new memory types unless >> >> defined by ACPI or otherwise sufficiently described by >> >> E820_RESERVED? >> > >> > Because it would make the kernel more functional? We should >> > always err on the side of allowing more functionality and >> > not erect roadblocks. >> > >> >> I'm not convinced Linux is better off enabling one-off >> BIOS implementations to pick non-standard numbers. Would >> it not be safer to at least confirm with the user via a >> configuration option, "do you want drivers to access >> unknown memory types"? > > Well, we could emit a warning (or taint the kernel), to > keep the user informed that there's a version mismatch > between kernel and firmware - but otherwise still allow > informed drivers to register that region? Sounds good to me. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
* Dan Williams wrote: > On Wed, Feb 18, 2015 at 10:53 AM, Ingo Molnar wrote: > > > > * Dan Williams wrote: > > > >> On Wed, Feb 18, 2015 at 10:30 AM, Ingo Molnar wrote: > >> > > >> > * Dan Williams wrote: > >> > > >> >> On Tue, Feb 17, 2015 at 12:42 AM, Boaz Harrosh > >> >> 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. > >> > > >> > Well, except when the kernel does know how to access > >> > it: when an nvdimm driver knows about its own memory > >> > region and knows how to handle it, right? > >> > >> Yes, except that "type-12" is something picked out of the > >> air that may be invalidated by a future spec change. > >> > >> If firmware wants any driver to handle a memory range it > >> can already use E820_RESERVED. The only reason a > >> new-type was picked in these early implementations was > >> for experiments around reserving nvdimm memory for driver > >> use, but also extending it to be covered with struct page > >> mappings. Outside of that there is no real driving > >> reason for the new type. > > > > But ... if a user is blessed/haunted with such firmware, > > why not let new types fall back to 'reserved', which is a > > reasonable default that still allows sufficiently aware > > Linux drivers to work, right? > > True. > > > > >> > So is there any practical reason to mark the memory > >> > resource as busy in that case, instead of just adding > >> > it to the reserved list by default and allowing > >> > properly informed drivers to (exclusively) request it? > >> > >> I'm not sure we want firmware to repeat this confusion > >> going forward. Why support new memory types unless > >> defined by ACPI or otherwise sufficiently described by > >> E820_RESERVED? > > > > Because it would make the kernel more functional? We should > > always err on the side of allowing more functionality and > > not erect roadblocks. > > > > I'm not convinced Linux is better off enabling one-off > BIOS implementations to pick non-standard numbers. Would > it not be safer to at least confirm with the user via a > configuration option, "do you want drivers to access > unknown memory types"? Well, we could emit a warning (or taint the kernel), to keep the user informed that there's a version mismatch between kernel and firmware - but otherwise still allow informed drivers to register that region? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On Wed, Feb 18, 2015 at 10:53 AM, Ingo Molnar wrote: > > * Dan Williams wrote: > >> On Wed, Feb 18, 2015 at 10:30 AM, Ingo Molnar wrote: >> > >> > * Dan Williams wrote: >> > >> >> On Tue, Feb 17, 2015 at 12:42 AM, Boaz Harrosh 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. >> > >> > Well, except when the kernel does know how to access >> > it: when an nvdimm driver knows about its own memory >> > region and knows how to handle it, right? >> >> Yes, except that "type-12" is something picked out of the >> air that may be invalidated by a future spec change. >> >> If firmware wants any driver to handle a memory range it >> can already use E820_RESERVED. The only reason a >> new-type was picked in these early implementations was >> for experiments around reserving nvdimm memory for driver >> use, but also extending it to be covered with struct page >> mappings. Outside of that there is no real driving >> reason for the new type. > > But ... if a user is blessed/haunted with such firmware, > why not let new types fall back to 'reserved', which is a > reasonable default that still allows sufficiently aware > Linux drivers to work, right? True. > >> > So is there any practical reason to mark the memory >> > resource as busy in that case, instead of just adding >> > it to the reserved list by default and allowing >> > properly informed drivers to (exclusively) request it? >> >> I'm not sure we want firmware to repeat this confusion >> going forward. Why support new memory types unless >> defined by ACPI or otherwise sufficiently described by >> E820_RESERVED? > > Because it would make the kernel more functional? We should > always err on the side of allowing more functionality and > not erect roadblocks. > I'm not convinced Linux is better off enabling one-off BIOS implementations to pick non-standard numbers. Would it not be safer to at least confirm with the user via a configuration option, "do you want drivers to access unknown memory types"? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
* Dan Williams wrote: > On Wed, Feb 18, 2015 at 10:30 AM, Ingo Molnar wrote: > > > > * Dan Williams wrote: > > > >> On Tue, Feb 17, 2015 at 12:42 AM, Boaz Harrosh 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. > > > > Well, except when the kernel does know how to access > > it: when an nvdimm driver knows about its own memory > > region and knows how to handle it, right? > > Yes, except that "type-12" is something picked out of the > air that may be invalidated by a future spec change. > > If firmware wants any driver to handle a memory range it > can already use E820_RESERVED. The only reason a > new-type was picked in these early implementations was > for experiments around reserving nvdimm memory for driver > use, but also extending it to be covered with struct page > mappings. Outside of that there is no real driving > reason for the new type. But ... if a user is blessed/haunted with such firmware, why not let new types fall back to 'reserved', which is a reasonable default that still allows sufficiently aware Linux drivers to work, right? > > So is there any practical reason to mark the memory > > resource as busy in that case, instead of just adding > > it to the reserved list by default and allowing > > properly informed drivers to (exclusively) request it? > > I'm not sure we want firmware to repeat this confusion > going forward. Why support new memory types unless > defined by ACPI or otherwise sufficiently described by > E820_RESERVED? Because it would make the kernel more functional? We should always err on the side of allowing more functionality and not erect roadblocks. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On Wed, Feb 18, 2015 at 10:30 AM, Ingo Molnar wrote: > > * Dan Williams wrote: > >> On Tue, Feb 17, 2015 at 12:42 AM, Boaz Harrosh 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. > > Well, except when the kernel does know how to access it: > when an nvdimm driver knows about its own memory region and > knows how to handle it, right? Yes, except that "type-12" is something picked out of the air that may be invalidated by a future spec change. If firmware wants any driver to handle a memory range it can already use E820_RESERVED. The only reason a new-type was picked in these early implementations was for experiments around reserving nvdimm memory for driver use, but also extending it to be covered with struct page mappings. Outside of that there is no real driving reason for the new type. > So is there any practical reason to mark the memory > resource as busy in that case, instead of just adding it to > the reserved list by default and allowing properly informed > drivers to (exclusively) request it? I'm not sure we want firmware to repeat this confusion going forward. Why support new memory types unless defined by ACPI or otherwise sufficiently described by E820_RESERVED? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
* Dan Williams wrote: > On Tue, Feb 17, 2015 at 12:42 AM, Boaz Harrosh 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. Well, except when the kernel does know how to access it: when an nvdimm driver knows about its own memory region and knows how to handle it, right? So is there any practical reason to mark the memory resource as busy in that case, instead of just adding it to the reserved list by default and allowing properly informed drivers to (exclusively) request it? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On Tue, Feb 17, 2015 at 12:42 AM, Boaz Harrosh 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On Tue, Feb 17, 2015 at 12:42 AM, Boaz Harrosh b...@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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
* Dan Williams dan.j.willi...@intel.com wrote: On Tue, Feb 17, 2015 at 12:42 AM, Boaz Harrosh b...@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. Well, except when the kernel does know how to access it: when an nvdimm driver knows about its own memory region and knows how to handle it, right? So is there any practical reason to mark the memory resource as busy in that case, instead of just adding it to the reserved list by default and allowing properly informed drivers to (exclusively) request it? Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
* Dan Williams dan.j.willi...@intel.com wrote: On Wed, Feb 18, 2015 at 10:30 AM, Ingo Molnar mi...@kernel.org wrote: * Dan Williams dan.j.willi...@intel.com wrote: On Tue, Feb 17, 2015 at 12:42 AM, Boaz Harrosh b...@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. Well, except when the kernel does know how to access it: when an nvdimm driver knows about its own memory region and knows how to handle it, right? Yes, except that type-12 is something picked out of the air that may be invalidated by a future spec change. If firmware wants any driver to handle a memory range it can already use E820_RESERVED. The only reason a new-type was picked in these early implementations was for experiments around reserving nvdimm memory for driver use, but also extending it to be covered with struct page mappings. Outside of that there is no real driving reason for the new type. But ... if a user is blessed/haunted with such firmware, why not let new types fall back to 'reserved', which is a reasonable default that still allows sufficiently aware Linux drivers to work, right? So is there any practical reason to mark the memory resource as busy in that case, instead of just adding it to the reserved list by default and allowing properly informed drivers to (exclusively) request it? I'm not sure we want firmware to repeat this confusion going forward. Why support new memory types unless defined by ACPI or otherwise sufficiently described by E820_RESERVED? Because it would make the kernel more functional? We should always err on the side of allowing more functionality and not erect roadblocks. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
* Dan Williams dan.j.willi...@intel.com wrote: On Wed, Feb 18, 2015 at 10:53 AM, Ingo Molnar mi...@kernel.org wrote: * Dan Williams dan.j.willi...@intel.com wrote: On Wed, Feb 18, 2015 at 10:30 AM, Ingo Molnar mi...@kernel.org wrote: * Dan Williams dan.j.willi...@intel.com wrote: On Tue, Feb 17, 2015 at 12:42 AM, Boaz Harrosh b...@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. Well, except when the kernel does know how to access it: when an nvdimm driver knows about its own memory region and knows how to handle it, right? Yes, except that type-12 is something picked out of the air that may be invalidated by a future spec change. If firmware wants any driver to handle a memory range it can already use E820_RESERVED. The only reason a new-type was picked in these early implementations was for experiments around reserving nvdimm memory for driver use, but also extending it to be covered with struct page mappings. Outside of that there is no real driving reason for the new type. But ... if a user is blessed/haunted with such firmware, why not let new types fall back to 'reserved', which is a reasonable default that still allows sufficiently aware Linux drivers to work, right? True. So is there any practical reason to mark the memory resource as busy in that case, instead of just adding it to the reserved list by default and allowing properly informed drivers to (exclusively) request it? I'm not sure we want firmware to repeat this confusion going forward. Why support new memory types unless defined by ACPI or otherwise sufficiently described by E820_RESERVED? Because it would make the kernel more functional? We should always err on the side of allowing more functionality and not erect roadblocks. I'm not convinced Linux is better off enabling one-off BIOS implementations to pick non-standard numbers. Would it not be safer to at least confirm with the user via a configuration option, do you want drivers to access unknown memory types? Well, we could emit a warning (or taint the kernel), to keep the user informed that there's a version mismatch between kernel and firmware - but otherwise still allow informed drivers to register that region? Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On Wed, Feb 18, 2015 at 10:30 AM, Ingo Molnar mi...@kernel.org wrote: * Dan Williams dan.j.willi...@intel.com wrote: On Tue, Feb 17, 2015 at 12:42 AM, Boaz Harrosh b...@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. Well, except when the kernel does know how to access it: when an nvdimm driver knows about its own memory region and knows how to handle it, right? Yes, except that type-12 is something picked out of the air that may be invalidated by a future spec change. If firmware wants any driver to handle a memory range it can already use E820_RESERVED. The only reason a new-type was picked in these early implementations was for experiments around reserving nvdimm memory for driver use, but also extending it to be covered with struct page mappings. Outside of that there is no real driving reason for the new type. So is there any practical reason to mark the memory resource as busy in that case, instead of just adding it to the reserved list by default and allowing properly informed drivers to (exclusively) request it? I'm not sure we want firmware to repeat this confusion going forward. Why support new memory types unless defined by ACPI or otherwise sufficiently described by E820_RESERVED? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On Wed, Feb 18, 2015 at 10:53 AM, Ingo Molnar mi...@kernel.org wrote: * Dan Williams dan.j.willi...@intel.com wrote: On Wed, Feb 18, 2015 at 10:30 AM, Ingo Molnar mi...@kernel.org wrote: * Dan Williams dan.j.willi...@intel.com wrote: On Tue, Feb 17, 2015 at 12:42 AM, Boaz Harrosh b...@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. Well, except when the kernel does know how to access it: when an nvdimm driver knows about its own memory region and knows how to handle it, right? Yes, except that type-12 is something picked out of the air that may be invalidated by a future spec change. If firmware wants any driver to handle a memory range it can already use E820_RESERVED. The only reason a new-type was picked in these early implementations was for experiments around reserving nvdimm memory for driver use, but also extending it to be covered with struct page mappings. Outside of that there is no real driving reason for the new type. But ... if a user is blessed/haunted with such firmware, why not let new types fall back to 'reserved', which is a reasonable default that still allows sufficiently aware Linux drivers to work, right? True. So is there any practical reason to mark the memory resource as busy in that case, instead of just adding it to the reserved list by default and allowing properly informed drivers to (exclusively) request it? I'm not sure we want firmware to repeat this confusion going forward. Why support new memory types unless defined by ACPI or otherwise sufficiently described by E820_RESERVED? Because it would make the kernel more functional? We should always err on the side of allowing more functionality and not erect roadblocks. I'm not convinced Linux is better off enabling one-off BIOS implementations to pick non-standard numbers. Would it not be safer to at least confirm with the user via a configuration option, do you want drivers to access unknown memory types? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On Wed, Feb 18, 2015 at 11:27 AM, Ingo Molnar mi...@kernel.org wrote: * Dan Williams dan.j.willi...@intel.com wrote: On Wed, Feb 18, 2015 at 10:53 AM, Ingo Molnar mi...@kernel.org wrote: * Dan Williams dan.j.willi...@intel.com wrote: On Wed, Feb 18, 2015 at 10:30 AM, Ingo Molnar mi...@kernel.org wrote: * Dan Williams dan.j.willi...@intel.com wrote: On Tue, Feb 17, 2015 at 12:42 AM, Boaz Harrosh b...@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. Well, except when the kernel does know how to access it: when an nvdimm driver knows about its own memory region and knows how to handle it, right? Yes, except that type-12 is something picked out of the air that may be invalidated by a future spec change. If firmware wants any driver to handle a memory range it can already use E820_RESERVED. The only reason a new-type was picked in these early implementations was for experiments around reserving nvdimm memory for driver use, but also extending it to be covered with struct page mappings. Outside of that there is no real driving reason for the new type. But ... if a user is blessed/haunted with such firmware, why not let new types fall back to 'reserved', which is a reasonable default that still allows sufficiently aware Linux drivers to work, right? True. So is there any practical reason to mark the memory resource as busy in that case, instead of just adding it to the reserved list by default and allowing properly informed drivers to (exclusively) request it? I'm not sure we want firmware to repeat this confusion going forward. Why support new memory types unless defined by ACPI or otherwise sufficiently described by E820_RESERVED? Because it would make the kernel more functional? We should always err on the side of allowing more functionality and not erect roadblocks. I'm not convinced Linux is better off enabling one-off BIOS implementations to pick non-standard numbers. Would it not be safer to at least confirm with the user via a configuration option, do you want drivers to access unknown memory types? Well, we could emit a warning (or taint the kernel), to keep the user informed that there's a version mismatch between kernel and firmware - but otherwise still allow informed drivers to register that region? Sounds good to me. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On Wed, Feb 18, 2015 at 10:15:32AM -0800, Dan Williams wrote: 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. Not supporting hardware that is widely avaiable (I have some, too) is not very user friendly. I'll submit a patch allowing a nvdimm_type= kernel option that allows to detect them, but will do nothing by default. The code needed is very small and it would be very useful for all kinds of projects. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
On Wed, Feb 18, 2015 at 4:47 PM, Christoph Hellwig h...@infradead.org wrote: On Wed, Feb 18, 2015 at 10:15:32AM -0800, Dan Williams wrote: 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. Not supporting hardware that is widely avaiable (I have some, too) is not very user friendly. Yes, as I agreed with Ingo, allowing a driver to assume control of an unknown memory type with a warning or a kernel taint seems fine. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips
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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
