[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1303263653.3464.65.camel@localhost>
Date: Wed, 20 Apr 2011 02:40:53 +0100
From: Ben Hutchings <ben@...adent.org.uk>
To: Hans Rosenfeld <hans.rosenfeld@....com>
Cc: linux-kernel@...r.kernel.org, stable@...nel.org,
akpm@...ux-foundation.org, "H. Peter Anvin" <hpa@...ux.intel.com>,
torvalds@...ux-foundation.org, stable-review@...nel.org,
alan@...rguk.ukuu.org.uk, Greg KH <gregkh@...e.de>
Subject: Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400
workaround
On Tue, 2011-04-19 at 13:30 -0700, Greg KH wrote:
> 2.6.32-longterm review patch. If anyone has any objections, please let us know.
>
> ------------------
>
> From: Hans Rosenfeld <hans.rosenfeld@....com>
>
> commit 9d8888c2a214aece2494a49e699a097c2ba9498b upstream.
>
> Remove check_c1e_idle() and use the new AMD errata checking framework
> instead.
Clean-up patches are generally not candidates for longterm updates.
However, I notice that the range of procesors considered to have erratum
400 was also changed:
[...]
> +const int amd_erratum_400[] =
> + AMD_OSVW_ERRATUM(1, AMD_MODEL_RANGE(0xf, 0x41, 0x2, 0xff, 0xf),
> + AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf));
[...]
> - /* Family 0x0f models < rev F do not have C1E */
> - if (c->x86 == 0x0F && c->x86_model >= 0x40)
> - return 1;
> -
> - if (c->x86 == 0x10) {
> - /*
> - * check OSVW bit for CPUs that are not affected
> - * by erratum #400
> - */
> - if (cpu_has(c, X86_FEATURE_OSVW)) {
[...]
> - }
> - return 1;
[...]
Family 0x0f model 0x40 and model 0x41 stepping 0 and 1 are excluded.
Family 0x10 model 0x00, 0x01 and model 0x02 stepping 0 are excluded.
Is that the real fix here?
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)
Powered by blists - more mailing lists