[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120912154943.GB12103@aftab.osrc.amd.com>
Date: Wed, 12 Sep 2012 17:49:43 +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 10:37:18AM -0500, Josh Hunt wrote:
> 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.
Yes, that's because the whole init_csrows thing has been b0rked since
forever. In your case, amd64_csrow_nr_pages() should pay attention to
the dct (second argument) which on K8 is always 0 (we have only one DCT
aka Dram ConTroller on K8) and the function should return 0 if dct is 1.
But the whole loop in init_csrows is fishy too so I'll need to rework
that properly. Oh well...
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/
Powered by blists - more mailing lists