Re: [PATCH] amd64_edac: Memory size reported double on processorfamily 0Fh

From: Josh Hunt
Date: Wed Sep 12 2012 - 11:37:36 EST

On 09/12/2012 10:30 AM, Borislav Petkov wrote:
Yes, you're basically right. Here's what I see from here:

In 2009 I added

commit 603adaf6b3e37450235f0ddb5986b961b3146a79
Author: Borislav Petkov <borislav.petkov@xxxxxxx>
Date: Mon Dec 21 14:52:53 2009 +0100

amd64_edac: fix K8 chip select reporting

Fix the case when amd64_debug_display_dimm_sizes() reports only half the
amount of DRAM on it because it doesn't account for when the single DCT
operates in 128-bit mode and merges chip selects from different DIMMs.

which was supposed to fix a bug-report of DRAM chip selects being halved
in reporting.


commit 41d8bfaba70311c2fa0666554ef160ea8ffc9daf
Author: Borislav Petkov <borislav.petkov@xxxxxxx>
Date: Tue Jan 18 19:16:08 2011 +0100

amd64_edac: Improve DRAM address mapping

Drop static tables which map the bits in F2x80 to a chip select size in
favor of functions doing the mapping with some bit fiddling. Also, add
F15 support.

two years later reworked the whole DBAM to chip select sizes mapping for
all families. But it left in the clumsy workaround above for K8 only,
thus the double shifting.

So, long story short, reverting 603adaf6b3e37450235f0ddb5986b961b3146a79
should probably fix the issue since it is not needed anymore.

Let me run it here to make sure I'm not missing anything else.


Well from what I see 603ad... would only fix the case of printing the values correctly on boot, by removing the factor=1 shift. However, that is merely cosmetic as it does not affect the actual calculation of nr_pages. I guess maybe I wasn't completely clear before, but I see the doubling of the amount of memory both on boot via dmesg, but also in /sys/devices/system/edac/mc/mc0/size_mb and all of the csrow* subdirs therein.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at