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.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.
--
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 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/
