A new Athlon 'bug'.

A new Athlon 'bug'.

[davej]

Very recent Athlons (Model 8 stepping 1 and above) (XPs/MPs and mobiles)
have an interesting problem.  Certain bits in the CLK_CTL register need
to be programmed differently to those in earlier models. The problem arises
when people plug these new CPUs into boards running BIOSes that are unaware
of this fact.

The fix is to reprogram CLK_CTL to 200xxxxx instead of 0x600xxxxx as it was
in previous models. The AMD folks have found that this improves stability.

The patch below does this reprogramming if an affected model/bios is
detected. 

I'm interested if someone with an affected model could run some
benchmarks before and after to also see if this affects performance.

		Dave

diff -urpN --exclude-from=/home/davej/.exclude bk-linus/arch/i386/kernel/cpu/amd.c linux-2.5/arch/i386/kernel/cpu/amd.c
--- bk-linus/arch/i386/kernel/cpu/amd.c	2002-11-21 02:09:31.000000000 +0000
+++ linux-2.5/arch/i386/kernel/cpu/amd.c	2002-11-21 15:31:56.000000000 +0000
@@ -164,12 +164,23 @@ static void __init init_amd(struct cpuin
 					set_bit(X86_FEATURE_XMM, c->x86_capability);
 				}
 			}
-			break;
 
+			/* It's been determined by AMD that Athlons since model 8 stepping 1
+			 * are more robust with CLK_CTL set to 200xxxxx instead of 600xxxxx
+			 * As per AMD technical note 27212 0.2
+			 */
+			if ((c->x86_model == 8 && c->x86_mask>=1) || (c->x86_model > 8)) {
+				rdmsr(MSR_K7_CLK_CTL, l, h);
+				if ((l & 0xfff00000) != 0x20000000) {
+					printk ("CPU: CLK_CTL MSR was %x. Reprogramming to %x\n", l,
+						((l & 0x000fffff)|0x20000000));
+					wrmsr(MSR_K7_CLK_CTL, (l & 0x000fffff)|0x20000000, h);
+				}
+			}
+			break;
 	}
 
 	display_cacheinfo(c);
-//	return r;
 }
 
 static unsigned int amd_size_cache(struct cpuinfo_x86 * c, unsigned int size)
diff -urpN --exclude-from=/home/davej/.exclude bk-linus/include/asm-i386/msr.h linux-2.5/include/asm-i386/msr.h
--- bk-linus/include/asm-i386/msr.h	2002-11-21 02:21:51.000000000 +0000
+++ linux-2.5/include/asm-i386/msr.h	2002-11-21 15:40:18.000000000 +0000
@@ -107,6 +107,7 @@
 #define MSR_K7_PERFCTR2			0xC0010006
 #define MSR_K7_PERFCTR3			0xC0010007
 #define MSR_K7_HWCR			0xC0010015
+#define MSR_K7_CLK_CTL			0xC001001b
 #define MSR_K7_FID_VID_CTL		0xC0010041
 #define MSR_K7_VID_STATUS		0xC0010042
 

Re: A new Athlon 'bug'.

[Pavel Machek]

Hi!

> Very recent Athlons (Model 8 stepping 1 and above) (XPs/MPs and mobiles)
> have an interesting problem.  Certain bits in the CLK_CTL register need
> to be programmed differently to those in earlier models. The problem arises
> when people plug these new CPUs into boards running BIOSes that are unaware
> of this fact.

What happens when bit is programed wrongly?

-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Re: A new Athlon 'bug'.

[Dave Jones]

On Mon, Nov 25, 2002 at 10:34:47PM +0100, Pavel Machek wrote:

 > > Very recent Athlons (Model 8 stepping 1 and above) (XPs/MPs and mobiles)
 > > have an interesting problem.  Certain bits in the CLK_CTL register need
 > > to be programmed differently to those in earlier models. The problem arises
 > > when people plug these new CPUs into boards running BIOSes that are unaware
 > > of this fact.
 > What happens when bit is programed wrongly?

The documentation I have says nothing other than "...platforms are more
robust..." with the fix. It's purely a reliability thing, but as it's
fiddling with the CPU clock, it's possible that it may *slightly*
affect performance too.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: A new Athlon 'bug'.

[Daniel Nofftz]

On Tue, 26 Nov 2002, Dave Jones wrote:

> On Mon, Nov 25, 2002 at 10:34:47PM +0100, Pavel Machek wrote:
>  > What happens when bit is programed wrongly?
>
> The documentation I have says nothing other than "...platforms are more
> robust..." with the fix. It's purely a reliability thing, but as it's
> fiddling with the CPU clock, it's possible that it may *slightly*
> affect performance too.

hi!
maybe somone remembers that i hacked a little bit with the power saving
modes of the athlon processor. so far as i know, the clk_ctl register is
importand when the athlon processor comes back from acpi-c2 mode. in c2 he
is disconnected from the system bus and the internal clock is clocked
down. in some cases a false value in this register could prevent the
athlon processor to come back from c2 -> lockup of the machine or
something like it ...
(bug 11 of the athlon processor revision guide)

daniel


# Daniel Nofftz .......................... #
# Sysadmin CIP-Pool Informatik ........... #
# University of Trier(Germany), Room V 103 #

The resonable man adapts himself to the world. The unreasonable
man persists in trying to adapt the world to himself. It follows
that all progress depends on the unresaonable man.
                                        George Bernard Shaw

Re: A new Athlon 'bug'.

[Dave Jones]

On Fri, Nov 29, 2002 at 04:08:32PM +0100, Daniel Nofftz wrote:

 > maybe somone remembers that i hacked a little bit with the power saving
 > modes of the athlon processor. so far as i know, the clk_ctl register is
 > importand when the athlon processor comes back from acpi-c2 mode. in c2 he
 > is disconnected from the system bus and the internal clock is clocked
 > down. in some cases a false value in this register could prevent the
 > athlon processor to come back from c2 -> lockup of the machine or
 > something like it ...

Correct. It contains values that indicate to the CPU how to ramp up
the CPU clock during low-power modes.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs