From: Josh Hunt <johunt@akamai.com>
To: Borislav Petkov <bp@amd64.org>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] amd64_edac: Memory size reported double on processor family 0Fh
Date: Wed, 12 Sep 2012 07:52:15 -0500 [thread overview]
Message-ID: <5050857F.5060207@akamai.com> (raw)
In-Reply-To: <5050824B.9050006@akamai.com>
On 09/12/2012 07:38 AM, Josh Hunt wrote:
> On 09/12/2012 03:51 AM, Borislav Petkov wrote:
>> On Tue, Sep 11, 2012 at 06:02:01PM -0500, Josh Hunt wrote:
>>> On 09/11/2012 05:52 PM, Josh Hunt wrote:
>>>> With recent kernels we noticed that edac was reporting double the memory size on
>>>> systems running with AMD family 0Fh processors. I'm not very familiar with the
>>>> code, but this resolves it from what I can see on my systems. At least in
>>>> amd64_debug_display_dimm_sizes() and k8_dbam_to_chip_select() there appeared
>>>> to be redundant shifts to the left by 1 when WIDTH_128 is present.
>>
>> Any chance you could enable CONFIG_EDAC_DEBUG, boot and send me your
>> whole dmesg? Privately is fine too.
>>
>> Thanks.
>>
>
> Sure. Attached. This is booting with latest git.
>
> Josh
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.
Josh
next prev parent reply other threads:[~2012-09-12 12:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1347403947-20187-1-git-send-email-johunt@akamai.com>
2012-09-11 23:02 ` [PATCH] amd64_edac: Memory size reported double on processor family 0Fh Josh Hunt
2012-09-12 8:51 ` Borislav Petkov
2012-09-12 12:38 ` Josh Hunt
2012-09-12 12:52 ` Josh Hunt [this message]
2012-09-12 15:30 ` Borislav Petkov
2012-09-12 15:37 ` Josh Hunt
2012-09-12 15:49 ` Borislav Petkov
2012-09-12 16:23 ` Josh Hunt
2012-09-12 16:48 ` Borislav Petkov
2012-09-12 16:58 ` Josh Hunt
2012-09-12 17:06 ` Borislav Petkov
2012-09-12 17:23 ` Borislav Petkov
2012-09-14 12:55 ` Josh Hunt
2012-09-14 14:39 ` Josh Hunt
2012-09-14 15:40 ` Borislav Petkov
2012-09-21 12:36 ` Borislav Petkov
2012-09-21 13:02 ` Josh Hunt
2012-09-21 14:01 ` Borislav Petkov
2012-09-21 14:54 ` Josh Hunt
2012-09-21 15:10 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5050857F.5060207@akamai.com \
--to=johunt@akamai.com \
--cc=bp@amd64.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox