From: Florian Weimer <fw@deneb.enyo.de>
To: Andi Kleen <ak@suse.de>
Cc: linux-kernel@vger.kernel.org, discuss@x86-64.org
Subject: Re: [PATCH] AMD64: fix mce_cpu_quirks typos
Date: Thu, 02 Feb 2006 13:59:05 +0100 [thread overview]
Message-ID: <87d5i5or1i.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <200602012143.19867.ak@suse.de> (Andi Kleen's message of "Wed, 1 Feb 2006 21:43:19 +0100")
* Andi Kleen:
> On Wednesday 01 February 2006 21:21, Florian Weimer wrote:
>
>> > but it's still logged and the regular polling picks them up
>> > anyways. I have not found a nice way to handle this (other than
>> > adding a ugly CPU specific special case in the middle of the nice
>> > cpu independent machine check handler, which I couldn't bring myself
>> > to do so far...)
>>
>> Someone tried to track these messages down together with someone else
>> from AMD, but they never got it finished.
>
> They could have saved themselves a lot of work by just asking
> at the right mailing lists (which is not l-k BTW)
Marc Michelsen brought this up last year on <discuss@x86-64.org>
(which I suppose is the right list), but he didn't receive many
comments (not publicly, at least).
> The 64bit kernel uses the AGP aperture as IOMMU, the 32bit kernel
> doesn't. It's a known documented hardware bug that this causes
> spurious GART errors.
Someone from AMD told Marc that fixes in pci-gart.c (probably related
to iommu_fullflush, see the comment there) are supposed to suppress
the error in the first place. That's why we are a bit confused
whether the errors are really harmless (our machines do run stable,
though).
It also seems that the bug is not as well-documented as it deserves to
be. (The search engines will pick up this thread, though.) Our
vendor told us to have the RAM tested, for instance. 8->
> That is why the BIOS and Linux disable them. Unfortunately the Linux
> MCE handler is too thorough and picks them up anyways as corrected
> events.
If the errors are really harmless, it probably makes sense to add a
warning to the mcelog output that this MCE is expected, preferably
with an AMD errata reference.
Filtering in the kernel seems to be overkill because the rate of those
spurious MCEs is fairly low, and they won't lead to loss of other,
more important MCEs.
next prev parent reply other threads:[~2006-02-02 12:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87fyn2yjpr.fsf@mid.deneb.enyo.de.suse.lists.linux.kernel>
2006-02-01 19:59 ` [PATCH] AMD64: fix mce_cpu_quirks typos Andi Kleen
2006-02-01 20:21 ` Florian Weimer
2006-02-01 20:43 ` Andi Kleen
2006-02-02 12:59 ` Florian Weimer [this message]
2006-02-02 13:17 ` [discuss] " Andi Kleen
2006-02-01 19:14 Florian Weimer
2006-02-01 19:44 ` Dave Jones
2006-02-01 19:49 ` Florian Weimer
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=87d5i5or1i.fsf@mid.deneb.enyo.de \
--to=fw@deneb.enyo.de \
--cc=ak@suse.de \
--cc=discuss@x86-64.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