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