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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 12 Sep 2012 10:37:18 -0500
From:	Josh Hunt <johunt@...mai.com>
To:	Borislav Petkov <bp@...64.org>
CC:	"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [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 <borislav.petkov@....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@....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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/