[lkml]   [2012]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] amd64_edac: Memory size reported double on processor family 0Fh
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 <>
> 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 <>
> 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


 \ /
  Last update: 2012-09-12 18:21    [W:0.093 / U:2.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site