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.pet...@amd.com> 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. But, commit 41d8bfaba70311c2fa0666554ef160ea8ffc9daf Author: Borislav Petkov <borislav.pet...@amd.com> 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. Thanks.
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.
Josh -- 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/
