From: Andi Kleen <andi@firstfloor.org>
To: Max Asbock <masbock@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com
Subject: Re: x86 32-bit machine check handler
Date: Tue, 13 Nov 2007 15:15:47 +0100 [thread overview]
Message-ID: <p73abpiz0x8.fsf@bingen.suse.de> (raw)
In-Reply-To: <1194899975.9979.7.camel@w-amax.beaverton.ibm.com> (Max Asbock's message of "Mon\, 12 Nov 2007 12\:39\:35 -0800")
Max Asbock <masbock@us.ibm.com> writes:
> Now that the 32-bit and 64-bit x86 machine check handlers live next to
> each other a certain asymmetry in functionality is apparent. Notably,
> the 64-bit machine check handler implements a timer that periodically
> polls for silent machine check errors and makes them accessible to user
> space through /dev/mcelog.
Actually 32bit implements that too (non-fatal.c). But it misses some
of the more advanced functionality like AMD Threshold Interrupts.
> Are there reasons the x86 32-bit machine
> check handler couldn't do the same?
The 32bit machine check code has some serious design problems. The
best would be probably to just move 32bit over to the 64bit code too. In
fact there was a patch to do that some time ago, but it ran into some
minor problems and was unfortunately never merged. But it would be the
right thing to do.
The only missing functionality on the 64bit side would be support for
old non IA compliant old machine checks like P5 or WinChip. One option
would be to simply drop them. AFAIK these CPUs don't really have
anywhere near usable machine check capability anyways so dropping it
would not make much difference. Or alternatively keep p5.c/winchip.c
around. But if you look at them they don't do much except simple
printk with not much information and printk in a machine check handler
is always wrong because it can deadlock. I personally would prefer
dropping.
And I think one or two K7 quirks are also missing on 64bit, but these
would be very easy to add. Other than that it should just work on
32bit CPUs.
-Andi
next prev parent reply other threads:[~2007-11-13 14:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-12 20:39 x86 32-bit machine check handler Max Asbock
2007-11-12 21:20 ` H. Peter Anvin
2007-11-13 14:15 ` Andi Kleen [this message]
2007-11-15 1:06 ` Max Asbock
2007-11-15 5:36 ` Andi Kleen
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=p73abpiz0x8.fsf@bingen.suse.de \
--to=andi@firstfloor.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masbock@us.ibm.com \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
/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