Hi!
I have a machine with an Athlon64 with a Winchester core. It has a max
frequency of 2GHz, vid 0x6. The maximum vid allowed is 0x4. It has an
intermediate vid 0x8. RVO is 3.
When transitioning (phase1) from vid 0x8 to vid 0x6, it first increases
the vid to 6, and then proceeds increasing it three more steps. This of
course fails, because it overflows the maximum allowed vid 0x4.
My first attempt to fix this was to limit the vid to the max vid while
doing the rvo bump-up.
However, I believe that the real reason for the problem is that the
condition to start doing the rvo bump is wrong.
This patch should fix it:
diff -Nru a/arch/i386/kernel/cpu/cpufreq/powernow-k8.c b/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
--- a/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 2005-03-14 17:20:17 +01:00
+++ b/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 2005-03-14 17:20:17 +01:00
@@ -286,7 +286,7 @@
return 1;
}
- while ((rvosteps > 0) && ((data->rvo + data->currvid) > reqvid)) {
+ while ((rvosteps > 0) && ((data->currvid - data->rvo) > reqvid)) {
if (data->currvid == 0) {
rvosteps = 0;
} else {
if I understand the original intent of the second test in the while()
statement.
Any comments? Is my understanding of that bit of code correct?
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Hi!
Paul, can you comment on this one? I know that pn-k8 logic is quite
tricky... And BIOS tables are often wrong.
Pavel
> I have a machine with an Athlon64 with a Winchester core. It has a max
> frequency of 2GHz, vid 0x6. The maximum vid allowed is 0x4. It has an
> intermediate vid 0x8. RVO is 3.
>
> When transitioning (phase1) from vid 0x8 to vid 0x6, it first increases
> the vid to 6, and then proceeds increasing it three more steps. This of
> course fails, because it overflows the maximum allowed vid 0x4.
>
> My first attempt to fix this was to limit the vid to the max vid while
> doing the rvo bump-up.
>
> However, I believe that the real reason for the problem is that the
> condition to start doing the rvo bump is wrong.
>
> This patch should fix it:
>
> diff -Nru a/arch/i386/kernel/cpu/cpufreq/powernow-k8.c b/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
> --- a/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 2005-03-14 17:20:17 +01:00
> +++ b/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 2005-03-14 17:20:17 +01:00
> @@ -286,7 +286,7 @@
> return 1;
> }
>
> - while ((rvosteps > 0) && ((data->rvo + data->currvid) > reqvid)) {
> + while ((rvosteps > 0) && ((data->currvid - data->rvo) > reqvid)) {
> if (data->currvid == 0) {
> rvosteps = 0;
> } else {
>
> if I understand the original intent of the second test in the while()
> statement.
>
> Any comments? Is my understanding of that bit of code correct?
>
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Hi Pavel,
This is similar to the Sempron patch I put out a while ago -
that was a similar problem. Let Mark and I think about it for
a couple of days. I think there is a better way to fix this.
There are some new fields in the status register in newer
parts to give things like maxvid, and we are not using them
at present. They were added in a manner compatible with the
older parts. I think we may have a better solution to use
the new fields.
Paul.
> -----Original Message-----
> From: Pavel Machek [mailto:[email protected]]
> Sent: Monday, March 14, 2005 11:18 AM
> To: Vojtech Pavlik; Devriendt, Paul
> Cc: [email protected]; [email protected];
> [email protected]
> Subject: Re: PowerNow-K8 and Winchester CPUs
>
> Hi!
>
> Paul, can you comment on this one? I know that pn-k8 logic is quite
> tricky... And BIOS tables are often wrong.
> Pavel
>
> > I have a machine with an Athlon64 with a Winchester core.
> It has a max
> > frequency of 2GHz, vid 0x6. The maximum vid allowed is 0x4.
> It has an
> > intermediate vid 0x8. RVO is 3.
> >
> > When transitioning (phase1) from vid 0x8 to vid 0x6, it
> first increases
> > the vid to 6, and then proceeds increasing it three more
> steps. This of
> > course fails, because it overflows the maximum allowed vid 0x4.
> >
> > My first attempt to fix this was to limit the vid to the
> max vid while
> > doing the rvo bump-up.
> >
> > However, I believe that the real reason for the problem is that the
> > condition to start doing the rvo bump is wrong.
> >
> > This patch should fix it:
> >
> > diff -Nru a/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
> b/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
> > --- a/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
> 2005-03-14 17:20:17 +01:00
> > +++ b/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
> 2005-03-14 17:20:17 +01:00
> > @@ -286,7 +286,7 @@
> > return 1;
> > }
> >
> > - while ((rvosteps > 0) && ((data->rvo + data->currvid)
> > reqvid)) {
> > + while ((rvosteps > 0) && ((data->currvid - data->rvo) >
> reqvid)) {
> > if (data->currvid == 0) {
> > rvosteps = 0;
> > } else {
> >
> > if I understand the original intent of the second test in
> the while()
> > statement.
> >
> > Any comments? Is my understanding of that bit of code correct?
> >
>
> --
> People were complaining that M$ turns users into beta-testers...
> ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
>
>