Re: [PATCH 0/2] AMD ARAT fixes
From: Chuck Ebbert
Date: Fri May 20 2011 - 10:43:10 EST
On Wed, 18 May 2011 17:50:17 +0200
Borislav Petkov <bp@xxxxxxxxx> wrote:
> Hi Greg,
> Ingo just confirmed that the following two fixes went upstream. I
> haven't tagged them for stable so I'd appreciate if you could take them
> for the next cycle. AFAICT, the relevant trees should be .38-stable,
> 32-longterm and 33-longterm.
> There should be no problem cherry-picking them but if there is, please
> let me know and I'll give you rebased versions.
> Here the commit ids again, for reference:
This still leaves family 10h model 6 stepping 2 (and possibly others)
broken in -stable as well as 2.6.39.
Looking at -stable, this whole mess was caused by:
x86, AMD: Set ARAT feature on AMD processors
That caused stalls on family 0fh and family 10h processors, and then
the (partial) fix for that in 188.8.131.52:
x86, AMD: Fix APIC timer erratum 400 affecting K8 Rev.A-E processors
caused instant crashes on boot on older family 0fh processors.
Now it looks like family 0fh is finally fixed in 184.108.40.206.
But I can't find any reason for the original commit that went in 220.127.116.11
to be there in the first place. It doesn't fix any bug whatsoever and
appears to be just a performance enhancement. So how did it get there?
I came up with this (untested) hack for now to fix the remaining bug,
should something like this go in -stable to fix family 10h until a
better way is found?
@@ -724,6 +724,15 @@ bool cpu_has_amd_erratum(const int *erra
+ * Temporary workaround for ARAT bug on Sempron.
+ * The BIOS clears the bit in OSVW, so the check
+ * fails, then ARAT gets set and when the processor
+ * uses C3 it hangs. Always return true for that CPU.
+ if (cpu->x86 == 0x10 && cpu->x86_model == 6 && cpu->x86_mask == 2)
+ return true;
* Must match family-model-stepping range first so that the
* range checks will override OSVW checking.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/