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

[Josh Hunt <johunt@akamai.com>]

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@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.petkov@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