[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <p73abpiz0x8.fsf@bingen.suse.de>
Date: Tue, 13 Nov 2007 15:15:47 +0100
From: Andi Kleen <andi@...stfloor.org>
To: Max Asbock <masbock@...ibm.com>
Cc: lkml <linux-kernel@...r.kernel.org>, tglx@...utronix.de,
mingo@...hat.com, hpa@...or.com
Subject: Re: x86 32-bit machine check handler
Max Asbock <masbock@...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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists