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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.