From: Borislav Petkov <[email protected]>
Hi all,
the following 2 patches address the fallout caused by
b87cf80af3ba4b4c008b4face3c68d604e1715c6. They enable ARAT only on
Fam10h and later, and leaves out K8 due to multiple problems there.
Although the patches look almost trivial, I'd like to ask Nick and
Jörg-Volker to test them, please, so that we can have a confirmation,
just in case.
Then, if we're lucky and Linus hasn't released .39 yet, we might sneak
them in, if we ask people politely :).
Thanks.
From: Borislav Petkov <[email protected]>
This reverts commit e20a2d205c05cef6b5783df339a7d54adeb50962.
Moving the lower endpoint of the Erratum 400 check to accomodate earlier
K8 revisions (A-E) opens a can of worms which is simply not worth to fix
properly by tweaking the errata checking framework:
* missing IntPenging MSR on revisions < CG cause #GP:
http://marc.info/?l=linux-kernel&m=130541471818831
* makes earlier revisions use the LAPIC timer instead of the C1E idle
routine which switches to HPET, thus not waking up in deeper C-states:
http://lkml.org/lkml/2011/4/24/20
Therefore, leave the original boundary starting with K8-revF.
---
arch/x86/kernel/cpu/amd.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index bb9eb29..3532d3b 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -698,7 +698,7 @@ cpu_dev_register(amd_cpu_dev);
*/
const int amd_erratum_400[] =
- AMD_OSVW_ERRATUM(1, AMD_MODEL_RANGE(0x0f, 0x4, 0x2, 0xff, 0xf),
+ AMD_OSVW_ERRATUM(1, AMD_MODEL_RANGE(0xf, 0x41, 0x2, 0xff, 0xf),
AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf));
EXPORT_SYMBOL_GPL(amd_erratum_400);
--
1.7.4.rc2
From: Borislav Petkov <[email protected]>
Trying to enable the local APIC timer on early K8 revisions uncovers
a number of other issues with it, in conjunction with the C1E enter
path on AMD. Fixing those causes much more churn and troubles than the
benefit of using that timer brings so don't enable it on K8 at all,
falling back to the original functionality the kernel had wrt to that.
Reported-and-bisected-by: Nick Bowler <[email protected]>
Cc: Boris Ostrovsky <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Borislav Petkov <[email protected]>
---
arch/x86/kernel/cpu/amd.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 3532d3b..6f9d1f6 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -613,7 +613,7 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
#endif
/* As a rule processors have APIC timer running in deep C states */
- if (c->x86 >= 0xf && !cpu_has_amd_erratum(amd_erratum_400))
+ if (c->x86 > 0xf && !cpu_has_amd_erratum(amd_erratum_400))
set_cpu_cap(c, X86_FEATURE_ARAT);
/*
--
1.7.4.rc2
Commit-ID: 14fb57dccb6e1defe9f89a66f548fcb24c374c1d
Gitweb: http://git.kernel.org/tip/14fb57dccb6e1defe9f89a66f548fcb24c374c1d
Author: Borislav Petkov <[email protected]>
AuthorDate: Tue, 17 May 2011 14:55:19 +0200
Committer: Ingo Molnar <[email protected]>
CommitDate: Tue, 17 May 2011 15:28:34 +0200
x86, AMD: Fix ARAT feature setting again
Trying to enable the local APIC timer on early K8 revisions
uncovers a number of other issues with it, in conjunction with
the C1E enter path on AMD. Fixing those causes much more churn
and troubles than the benefit of using that timer brings so
don't enable it on K8 at all, falling back to the original
functionality the kernel had wrt to that.
Reported-and-bisected-by: Nick Bowler <[email protected]>
Cc: Boris Ostrovsky <[email protected]>
Cc: Andreas Herrmann <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Hans Rosenfeld <[email protected]>
Cc: Nick Bowler <[email protected]>
Cc: Joerg-Volker-Peetz <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/kernel/cpu/amd.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 3532d3b..6f9d1f6 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -613,7 +613,7 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
#endif
/* As a rule processors have APIC timer running in deep C states */
- if (c->x86 >= 0xf && !cpu_has_amd_erratum(amd_erratum_400))
+ if (c->x86 > 0xf && !cpu_has_amd_erratum(amd_erratum_400))
set_cpu_cap(c, X86_FEATURE_ARAT);
/*
Borislav Petkov wrote, on 05/17/11 14:55:
> From: Borislav Petkov <[email protected]>
>
> Hi all,
>
> the following 2 patches address the fallout caused by
> b87cf80af3ba4b4c008b4face3c68d604e1715c6. They enable ARAT only on
> Fam10h and later, and leaves out K8 due to multiple problems there.
>
> Although the patches look almost trivial, I'd like to ask Nick and
> Jörg-Volker to test them, please, so that we can have a confirmation,
> just in case.
>
> Then, if we're lucky and Linus hasn't released .39 yet, we might sneak
> them in, if we ask people politely :).
>
> Thanks.
>
>
A kernel version 2.6.38.6 patched with your two patches modifying only
arch/x86/kernel/cpu/amd.c starts and runs without problems on the affected
system with a AMD Turion 64 processor. The system is pure x86_64 (Debian
Release: wheezy/sid) with gcc version 4.6.1 20110428 (prerelease) (Debian
4.6.0-6) and GNU C Library (Debian EGLIBC 2.13-4) stable release version 2.13.
The only obvious difference I see is the message "using C1E aware idle routine"
in dmesg.
--
Best regards,
Jörg-Volker.
On Tue, May 17, 2011 at 12:38:46PM -0400, J?rg-Volker Peetz wrote:
> A kernel version 2.6.38.6 patched with your two patches modifying only
> arch/x86/kernel/cpu/amd.c starts and runs without problems on the affected
> system with a AMD Turion 64 processor. The system is pure x86_64 (Debian
> Release: wheezy/sid) with gcc version 4.6.1 20110428 (prerelease) (Debian
> 4.6.0-6) and GNU C Library (Debian EGLIBC 2.13-4) stable release version 2.13.
Thanks for testing!
> The only obvious difference I see is the message "using C1E aware idle routine"
> in dmesg.
That was your CPU, right:
vendor_id : AuthenticAMD
cpu family : 15
model : 36
model name : AMD Turion(tm) 64 Mobile Technology MT-40
stepping : 2
?
If so, then the C1E idle line above shouldn't appear. Can you check that
around line 698 in <arch/x86/kernel/cpu/amd.c> you have the following:
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));
On your machine, you should be using the default_idle routine instead,
since you don't have C1E.
Thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
Borislav Petkov wrote, on 05/17/11 18:53:
> On Tue, May 17, 2011 at 12:38:46PM -0400, J?rg-Volker Peetz wrote:
>> A kernel version 2.6.38.6 patched with your two patches modifying only
>> arch/x86/kernel/cpu/amd.c starts and runs without problems on the affected
>> system with a AMD Turion 64 processor. The system is pure x86_64 (Debian
>> Release: wheezy/sid) with gcc version 4.6.1 20110428 (prerelease) (Debian
>> 4.6.0-6) and GNU C Library (Debian EGLIBC 2.13-4) stable release version 2.13.
>
> Thanks for testing!
>
>> The only obvious difference I see is the message "using C1E aware idle routine"
>> in dmesg.
>
> That was your CPU, right:
>
> vendor_id : AuthenticAMD
> cpu family : 15
> model : 36
> model name : AMD Turion(tm) 64 Mobile Technology MT-40
> stepping : 2
>
> ?
Yes, exactly.
>
> If so, then the C1E idle line above shouldn't appear. Can you check that
> around line 698 in <arch/x86/kernel/cpu/amd.c> you have the following:
>
> 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));
>
The lines 683--685 in this file on my affected system are equal to the three
lines above (except for formatting).
> On your machine, you should be using the default_idle routine instead,
> since you don't have C1E.
?
>
> Thanks.
>
On Tue, May 17, 2011 at 07:21:43PM +0200, J?rg-Volker Peetz wrote:
> Borislav Petkov wrote, on 05/17/11 18:53:
> > On Tue, May 17, 2011 at 12:38:46PM -0400, J?rg-Volker Peetz wrote:
> >> A kernel version 2.6.38.6 patched with your two patches modifying only
> >> arch/x86/kernel/cpu/amd.c starts and runs without problems on the affected
> >> system with a AMD Turion 64 processor. The system is pure x86_64 (Debian
> >> Release: wheezy/sid) with gcc version 4.6.1 20110428 (prerelease) (Debian
> >> 4.6.0-6) and GNU C Library (Debian EGLIBC 2.13-4) stable release version 2.13.
> >
> > Thanks for testing!
> >
> >> The only obvious difference I see is the message "using C1E aware idle routine"
> >> in dmesg.
> >
> > That was your CPU, right:
> >
> > vendor_id : AuthenticAMD
> > cpu family : 15
> > model : 36
> > model name : AMD Turion(tm) 64 Mobile Technology MT-40
> > stepping : 2
> >
> > ?
> Yes, exactly.
>
> >
> > If so, then the C1E idle line above shouldn't appear. Can you check that
> > around line 698 in <arch/x86/kernel/cpu/amd.c> you have the following:
> >
> > 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));
> >
> The lines 683--685 in this file on my affected system are equal to the three
> lines above (except for formatting).
Ok, let me confirm whether I understand you correctly: are you seeing
the C1E line _with_ the two patches applied or without?
I'm fairly certain that with the patches, you shouldn't be seeing the
line and the first patch is actually the fix for your machine where
you don't have to press a button to continue, AFAICT and if I'm not
completely on crack here.
Thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
Borislav Petkov wrote, on 05/17/11 19:46:
> On Tue, May 17, 2011 at 07:21:43PM +0200, J?rg-Volker Peetz wrote:
>> Borislav Petkov wrote, on 05/17/11 18:53:
>>> On Tue, May 17, 2011 at 12:38:46PM -0400, J?rg-Volker Peetz wrote:
>>>> A kernel version 2.6.38.6 patched with your two patches modifying only
>>>> arch/x86/kernel/cpu/amd.c starts and runs without problems on the affected
>>>> system with a AMD Turion 64 processor. The system is pure x86_64 (Debian
>>>> Release: wheezy/sid) with gcc version 4.6.1 20110428 (prerelease) (Debian
>>>> 4.6.0-6) and GNU C Library (Debian EGLIBC 2.13-4) stable release version 2.13.
>>>
>>> Thanks for testing!
>>>
>>>> The only obvious difference I see is the message "using C1E aware idle routine"
>>>> in dmesg.
>>>
>>> That was your CPU, right:
>>>
>>> vendor_id : AuthenticAMD
>>> cpu family : 15
>>> model : 36
>>> model name : AMD Turion(tm) 64 Mobile Technology MT-40
>>> stepping : 2
>>>
>>> ?
>> Yes, exactly.
>>
>>>
>>> If so, then the C1E idle line above shouldn't appear. Can you check that
>>> around line 698 in <arch/x86/kernel/cpu/amd.c> you have the following:
>>>
>>> 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));
>>>
>> The lines 683--685 in this file on my affected system are equal to the three
>> lines above (except for formatting).
>
> Ok, let me confirm whether I understand you correctly: are you seeing
> the C1E line _with_ the two patches applied or without?
>
> I'm fairly certain that with the patches, you shouldn't be seeing the
> line and the first patch is actually the fix for your machine where
> you don't have to press a button to continue, AFAICT and if I'm not
> completely on crack here.
>
> Thanks.
>
Yes, you are right, I saw it with the *unpatched* version. My mistake :-(
Sorry for the confusion and the trouble.
And thank you very much for caring.
--
Best regards,
J?rg-Volker.
On Tue, May 17, 2011 at 07:51:51PM +0200, J?rg-Volker Peetz wrote:
> Yes, you are right, I saw it with the *unpatched* version. My mistake :-(
> Sorry for the confusion and the trouble.
Don't mention it, I am sorry that we broke Linux on your machine in the
first place.
Thanks a lot for testing the patches.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
On 2011-05-17 14:55 +0200, Borislav Petkov wrote:
> Although the patches look almost trivial, I'd like to ask Nick and
> J?rg-Volker to test them, please, so that we can have a confirmation,
> just in case.
Works as advertised, both patches applied on top of 2.6.38.6.
Thanks,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
On Tue, May 17, 2011 at 06:30:22PM -0400, Nick Bowler wrote:
> On 2011-05-17 14:55 +0200, Borislav Petkov wrote:
> > Although the patches look almost trivial, I'd like to ask Nick and
> > J?rg-Volker to test them, please, so that we can have a confirmation,
> > just in case.
>
> Works as advertised, both patches applied on top of 2.6.38.6.
Great!
Thanks for testing them.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
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:
http://git.kernel.org/tip/14fb57dccb6e1defe9f89a66f548fcb24c374c1d
http://git.kernel.org/tip/328935e6348c6a7cb34798a68c326f4b8372e68a
Thanks.
On Tue, May 17, 2011 at 02:55:17PM +0200, Borislav Petkov wrote:
> From: Borislav Petkov <[email protected]>
>
> Hi all,
>
> the following 2 patches address the fallout caused by
> b87cf80af3ba4b4c008b4face3c68d604e1715c6. They enable ARAT only on
> Fam10h and later, and leaves out K8 due to multiple problems there.
>
> Although the patches look almost trivial, I'd like to ask Nick and
> J?rg-Volker to test them, please, so that we can have a confirmation,
> just in case.
>
> Then, if we're lucky and Linus hasn't released .39 yet, we might sneak
> them in, if we ask people politely :).
>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
On Wed, 18 May 2011 17:50:17 +0200
Borislav Petkov <[email protected]> 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:
>
> http://git.kernel.org/tip/14fb57dccb6e1defe9f89a66f548fcb24c374c1d
> http://git.kernel.org/tip/328935e6348c6a7cb34798a68c326f4b8372e68a
>
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:
commit b87cf80af3ba4b4c008b4face3c68d604e1715c6
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 2.6.38.6:
commit e20a2d205c05cef6b5783df339a7d54adeb50962
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 2.6.38.7.
But I can't find any reason for the original commit that went in 2.6.38.4
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?
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -724,6 +724,15 @@ bool cpu_has_amd_erratum(const int *erra
return false;
/*
+ * 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.
*/
On 05/20/2011 10:37 AM, Chuck Ebbert wrote:
> On Wed, 18 May 2011 17:50:17 +0200
> Borislav Petkov<[email protected]> 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:
>>
>> http://git.kernel.org/tip/14fb57dccb6e1defe9f89a66f548fcb24c374c1d
>> http://git.kernel.org/tip/328935e6348c6a7cb34798a68c326f4b8372e68a
>>
>
> 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:
>
> commit b87cf80af3ba4b4c008b4face3c68d604e1715c6
> 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 2.6.38.6:
>
> commit e20a2d205c05cef6b5783df339a7d54adeb50962
> 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 2.6.38.7.
>
> But I can't find any reason for the original commit that went in 2.6.38.4
> 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?
There will be a fix for this, hopefully next week. We need to do more
testing, which is why it's been taking longer than it should.
-boris
>
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -724,6 +724,15 @@ bool cpu_has_amd_erratum(const int *erra
> return false;
>
> /*
> + * 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.
> */
>