2002-11-21 15:51:42

by Dave Jones

[permalink] [raw]
Subject: A new Athlon 'bug'.

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



2002-11-26 19:25:06

by Pavel Machek

[permalink] [raw]
Subject: Re: A new Athlon 'bug'.

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?

2002-11-26 19:37:11

by Dave Jones

[permalink] [raw]
Subject: Re: A new Athlon 'bug'.

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

2002-11-29 15:01:13

by Daniel Nofftz

[permalink] [raw]
Subject: Re: A new Athlon 'bug'.

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

2002-11-29 15:07:08

by Dave Jones

[permalink] [raw]
Subject: Re: A new Athlon 'bug'.

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