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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20120912153016.GA12103@aftab.osrc.amd.com>
Date:	Wed, 12 Sep 2012 17:30:16 +0200
From:	Borislav Petkov <bp@...64.org>
To:	Josh Hunt <johunt@...mai.com>
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 Wed, Sep 12, 2012 at 07:52:15AM -0500, Josh Hunt wrote:
> I wanted to add that we started seeing this back in 3.0. I didn't go
> back any farther, but know it was not occurring in 2.6.38. The issue
> in 3.0 appeared to be that we shift left k8_dbam_to_chip_select()
> and there was also another shift in amd64_csrow_nr_pages(). It looks
> like that second shift has been replaced by a more recent patch,
> which actually checks to see if the csrow is enabled and then counts
> nr_pages again adding that to the first calculation, still resulting
> in the size being double.

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.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
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/