From: Andi Kleen <ak@colin2.muc.de>
To: Simon Garner <sgarner@expio.co.nz>
Cc: Andi Kleen <ak@muc.de>, linux-kernel@vger.kernel.org
Subject: Re: MSI K8D-Master - GART error 3
Date: 5 Aug 2003 15:42:41 +0200 [thread overview]
Date: Tue, 5 Aug 2003 15:42:41 +0200 [thread overview]
Message-ID: <20030805134241.GA63394@colin2.muc.de> (raw)
In-Reply-To: <028101c35aea$d2753690$0401a8c0@SIMON>
On Tue, Aug 05, 2003 at 12:45:01PM +1200, Simon Garner wrote:
> Andi Kleen <ak@muc.de> wrote:
>
> > There is nothing in any of my trees that generates such a message.
> > If it was GART related it would be either "GART TLB error ..." or
> > "extended error gart error". But even that should not happen anymore,
> > see below.
> >
> > I don't know what the RedHat kernel does, they may have changed the
> > MCE handler over the reference port.
> >
>
> A quick google brings up this reference:
> http://www.iglu.org.il/lxr/source/arch/x86_64/kernel/bluesmoke.c
Ok that's the very old MCE code that incorrectly enabled the northbridge
machine check. Don't use that or use mce=off. However I still think
it's a driver bug in your case. If it was the shakey GART MCE itself
you would get a panic because it's a unrecoverable MCE. More
likely the driver is accessing PCI DMA mappings after they got unmapped,
which is a serious bug, but somehow not serious enough that the
northbridge triggers the MCE.
I was confused by your statement that the SuSE 8.2 beta9 kernel
generated that. It didn't because it doesn't contain that old code.
What does a modern kernel like the SuSE one or a x86-64.org kernel
generate exactly?
>
> The error appears to be generated by the code starting around line 152
> in that file.
>
> Btw, what is 'bluesmoke'?
Alan Cox's sense of humour. Look it up in the jargon file.
> > You can always disable it with mce=off or better mce=0
> > as the message seems to be caused by the periodic non fatal MCE check
> > timer.
> >
>
> What will I lose by disabling this?
mce=0 turns off periodic MCE checking for non fatal errors.
That's not a big issue, the worst you lose is reporting of one bit
corrected ECC memory failures.
mce=off turns off MCE reporting for fatal MCE exceptions (however
your box may still crash when something really bad happens)
mce=0 should have turned off the periodic check and your
message very much looks like a periodic one, as actual MCE
exceptions report more data. I'm a bit puzzled why it doesn't
kill the message here. You can try mce=off, but I'm not
sure it will help neither.
Using a newer kernel is probably a good idea anyways, as there
were many bugfixes since then.
-Andi
next prev parent reply other threads:[~2003-08-05 13:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <gC1o.2gU.5@gated-at.bofh.it>
2003-08-05 0:11 ` Andi Kleen
2003-08-05 0:45 ` Simon Garner
2003-08-05 13:42 ` Andi Kleen [this message]
2003-08-10 22:43 ` Simon Garner
2003-08-10 22:56 ` Andi Kleen
2003-08-12 23:22 ` Simon Garner
2003-08-04 1:05 Simon Garner
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=20030805134241.GA63394@colin2.muc.de \
--to=ak@colin2.muc.de \
--cc=ak@muc.de \
--cc=linux-kernel@vger.kernel.org \
--cc=sgarner@expio.co.nz \
/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
Powered by JetHome