Skip to content

e820: Fix handling of NvDIMM chips

Boaz Harrosh linux-nvdimm lkml nvdimm 3 versions – In review

Get series with b4
b4 am [email protected]

Versions newest first · linked by author and title

  1. v5 Latest3 patches 15 repliesIn review
  2. v22 of 3 patches 10 repliesSuperseded
  3. v12 patches 21 repliesSuperseded

Patches in v5 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/3e820: Don't let unknown DIMM type come out BUSYarch/x86/kernel/e820.c+29 -22 replies
2/3resource: Add new flag IORESOURCE_MEM_WARNarch/x86/kernel/e820.c include/linux/ioport.h kernel/resource.c+14 -10 replies
3/3e820: Add the unknown-12 Memory type (DDR3-NvDIMM)arch/x86/kernel/e820.c+9 -011 replies

Reviews trailers per patch

None of the 3 patches has a Reviewed-by or Acked-by.

PatchRoss Zwisler
SeriesNeed-signed-by
1/3
2/3
3/3

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.

Read the v5 thread

Cover letter [PATCH 0/3 v5] e820: Fix handling of NvDIMM chips

Hi

[v5]
* [PATCH 2/3] Added the add_taint(TAINT_FIRMWARE_WORKAROUND,...) and changed the printed message as requested
* Use IORESOURCE_MEM_WARN bit from the mem specific bit range (not 64bit only anymore, only works with memory resources)
* Fix user visible typo reserved-unkown => reserved-unknown &&

	unkown-12 => unknown-12

* Select [PATCH 3A/3] (over [PATCH 3B/3])
* ...
* Also posting RFC of pmem as reference

[v2]
* Added warning at bring up about unknown type
* Added an extra patch to warn-print in request_resource
* changed name from NvDIMM-12 => unknown-12
I wish we would reconsider this. So we need to suffer until some unknown future when ACPI decides to reuse type-12. When this happens we can fix it then, NO?
* Now based on 4.0-rc1

[v1]
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.

Quoted 1 line

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.

For all the pmem people. I maintain a tree with these patches and latest pmem code here:

	git://git.open-osd.org/pmem.git (pmem branch)
	[web-view:http://git.open-osd.org/gitweb.cgi?p=pmem.git;a=summary]

List of patches:
[PATCH 1/3] e820: Don't let unknown DIMM type come out BUSY
The main fix

[PATCH 2/3] resource: Add new flag IORESOURCE_MEM_WARN
Warn in request_resource

[PATCH 3/3] e820: Add the unknown-12 Memory type (DDR3-NvDIMM)

Also submitted as reference is an RFC of the pmem driver that demonstrates the use of the add_resource API for the NvDIMM chips. This can be seen in pmem-patch-1. Also please see pmem-patch-8 an out-of-tree patch that ignores the add_resource failure so it can work with NvDIMMs with old kernels.

Thanks
Boaz

Read the cover letter in its thread