Cpufreq: powernow-k7 weirdness

Cpufreq: powernow-k7 weirdness

[Juliusz Chroboczek]

Running stock 2.5.73 (ACPI + preempt) on a Compaq Presario 711, CPU is
a 950MHz mobile Duron.  I'm getting unexpected timings when enabling
cpufreq.

On a kernel compiled without cpufreq, a CPU bound program (repeated
sieve within L1 cache) gives the following, which is consistent with
what I get under 2.4.18:

  real    0m1.729s
  user    0m1.725s
  sys     0m0.003s

On a kernel with cpufreq (powernow-k7), I get the following at boot time:
  
  powernow: AMD K7 CPU detected.
  powernow: PowerNOW! Technology present. Can scale: frequency and voltage.
  powernow: Found PSB header at c00f6b30
  powernow: Table version: 0x12
  powernow: Flags: 0x0 (Mobile voltage regulator)
  powernow: Settling Time: 100 microseconds.
  powernow: Has 36 PST tables. (Only dumping ones relevant to this CPU).
  powernow: PST:25 (@c00f6cb8)
  powernow:  cpuid: 0x771 fsb: 100        maxFID: 0xd     startvid: 0xb
  powernow:    FID: 0x4 (5.0x [500MHz])   VID: 0xe (1.300V)
  powernow:    FID: 0x8 (7.0x [700MHz])   VID: 0xe (1.300V)
  powernow:    FID: 0xd (9.5x [950MHz])   VID: 0xb (1.450V)

However, the timings I get are roughly 10% lower than what I'd
expect, namely as follows:

At 950 MHz:

  real    0m1.932s
  user    0m1.930s
  sys     0m0.002s

At 700 MHz:

  real    0m2.347s
  user    0m2.346s
  sys     0m0.002s

At 500 MHz:

  real    0m3.288s
  user    0m3.285s
  sys     0m0.003s

In all three cases, /proc/cpuinfo reflects the expected frequency.

If there's any more testing that I can do, please let me know by e-mail.

                                        Juliusz Chroboczek

P.S. I am not subscribed to the list, and would appreciate being CCd
     with any replies.

P.P.S. /proc/cpuinfo, under a non-powerstep kernel:

  processor       : 0
  vendor_id       : AuthenticAMD
  cpu family      : 6
  model           : 7
  model name      : Mobile AMD Duron(tm) Processor
  stepping        : 1
  cpu MHz         : 946.875
  cache size      : 64 KB
  fdiv_bug        : no
  hlt_bug         : no
  f00f_bug        : no
  coma_bug        : no
  fpu             : yes
  fpu_exception   : yes
  cpuid level     : 1
  wp              : yes
  flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
  bogomips        : 1863.68

Re: Cpufreq: powernow-k7 weirdness

[Ducrot Bruno]

On Sun, Jul 06, 2003 at 03:00:35AM +0200, Juliusz Chroboczek wrote:
> Running stock 2.5.73 (ACPI + preempt) on a Compaq Presario 711, CPU is
> a 950MHz mobile Duron.  I'm getting unexpected timings when enabling
> cpufreq.
> 
> On a kernel compiled without cpufreq, a CPU bound program (repeated
> sieve within L1 cache) gives the following, which is consistent with
> what I get under 2.4.18:
> 
>   real    0m1.729s
>   user    0m1.725s
>   sys     0m0.003s
> 

There is a little bug in powernow-k7.c

ducrot@neptune $  cvs diff -u -r1.42 powernow-k7.c
Index: powernow-k7.c
===================================================================
RCS file: /mnt/src/cvsroot/cpufreq/linux/arch/i386/kernel/cpufreq/powernow-k7.c,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- powernow-k7.c	16 Jun 2003 20:39:11 -0000	1.42
+++ powernow-k7.c	4 Jul 2003 15:18:55 -0000	1.43
@@ -1,5 +1,5 @@
 /*
- *  $Id: powernow-k7.c,v 1.42 2003/06/16 20:39:11 davej Exp $
+ *  $Id: powernow-k7.c,v 1.43 2003/07/04 15:18:55 ducrot Exp $
  *
  *  (C) 2003 Dave Jones <davej@suse.de>
  *
@@ -268,8 +268,8 @@
 		change_VID(vid);
 	} else {
 		/* Going up, so change VID first */
-		change_VID(fid);
-		change_FID(vid);
+		change_VID(vid);
+		change_FID(fid);
 	}
 	
 


It is not in mainline AFAIK.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: Cpufreq: powernow-k7 weirdness

[Carl Thompson]

Quoting Ducrot Bruno <ducrot@poupinou.org>:

> ...

> There is a little bug in powernow-k7.c

> ...

> -		change_VID(fid);
> -		change_FID(vid);
> +		change_VID(vid);
> +		change_FID(fid);

> ...

> It is not in mainline AFAIK.

This "little bug" caused my computer to repeatedly crash with 2.4.21-ac4 and
2.5.72!  Not sure if it's in more recent kernels, but it was definitely in
the mainline at that point.

Carl

Re: Cpufreq: powernow-k7 weirdness

[Jay Goodman Tamboli]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

On Sun, Jul 06, 2003 at 10:11:00AM -0700, Carl Thompson wrote:
> Quoting Ducrot Bruno <ducrot@poupinou.org>:
> 
> > ...
> 
> > There is a little bug in powernow-k7.c
> 
> > ...
> 
> > -		change_VID(fid);
> > -		change_FID(vid);
> > +		change_VID(vid);
> > +		change_FID(fid);
> 
> > ...
> 
> > It is not in mainline AFAIK.
> 
> This "little bug" caused my computer to repeatedly crash with 2.4.21-ac4 and
> 2.5.72!  Not sure if it's in more recent kernels, but it was definitely in
> the mainline at that point.

(new to the list, so hopefully not beating dead horse here)

Yeah, I found this in 2.4.21-ac4, too, and was having
crashes.  Fixing this bug still causes lockups if I change
the cpufreq too drastically.  Going from one setting to the
next (i.e. not skipping any available speeds) seems to work
ok, though.  This is a Sony FR130, so is this the effect of
the PST problems discussed earlier?

/jgt
-- 
You can't spell "deadly heart palpitations" without "h-a-p-p-y".
        -- Jason Zych, on uiuc.general

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Cpufreq: powernow-k7 weirdness

[Carl Thompson]

Quoting Jay Goodman Tamboli <jay@tamboli.cx>:

> ...

> Yeah, I found this in 2.4.21-ac4, too, and was having
> crashes.  Fixing this bug still causes lockups if I change
> the cpufreq too drastically.  Going from one setting to the
> next (i.e. not skipping any available speeds) seems to work
> ok, though.  This is a Sony FR130, so is this the effect of
> the PST problems discussed earlier?

No.  This is a problem I discovered a while back during testing of my CPU
speed setting daemon (see the list archives).  It's just that some CPUs /
chipsets require smooth rather than drastic transitions.  (In other words,
when switching from speed X to speed Y, you should switch to every speed in
between during the transition instead of directly.)  I believe only Mobile
AMD chips have this behavior.  I believe 2.5 has a fix in for this?  Also,
yy program automatically handles this for you when switching speeds; I will
definitely post a version today.

> /jgt

Carl Thompson

Re: Cpufreq: powernow-k7 weirdness

[Ducrot Bruno]

On Sun, Jul 06, 2003 at 10:43:05AM -0700, Carl Thompson wrote:
> Quoting Jay Goodman Tamboli <jay@tamboli.cx>:
> 
> > ...
> 
> > Yeah, I found this in 2.4.21-ac4, too, and was having
> > crashes.  Fixing this bug still causes lockups if I change
> > the cpufreq too drastically.  Going from one setting to the
> > next (i.e. not skipping any available speeds) seems to work
> > ok, though.  This is a Sony FR130, so is this the effect of
> > the PST problems discussed earlier?
> 
> No.  This is a problem I discovered a while back during testing of my CPU
> speed setting daemon (see the list archives).  It's just that some CPUs /
> chipsets require smooth rather than drastic transitions.  (In other words,
> when switching from speed X to speed Y, you should switch to every speed in
> between during the transition instead of directly.)  I believe only Mobile
> AMD chips have this behavior.  I believe 2.5 has a fix in for this?  Also,
> yy program automatically handles this for you when switching speeds; I will
> definitely post a version today.
> 

Things should be a little bit more smooth, but there is still deadlock
when for example you switch from max freq. to min.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: Cpufreq: powernow-k7 weirdness

[Luigi Belli]

On Sunday 06 July 2003 08:48 pm, Ducrot Bruno wrote:

> Things should be a little bit more smooth, but there is still deadlock
> when for example you switch from max freq. to min.

Never had problems switching max to min (and I do it every time I boot the 
system), min to max instead often freezes everything (and I'm undervolted, so 
virtually less stable).

Re: Cpufreq: powernow-k7 weirdness

[Michael Frank]

On Monday 07 July 2003 05:56, Luigi Belli wrote:
> On Sunday 06 July 2003 08:48 pm, Ducrot Bruno wrote:
> > Things should be a little bit more smooth, but there is still deadlock
> > when for example you switch from max freq. to min.
>
> Never had problems switching max to min (and I do it every time I boot the

You CPU can't scream oooouch...

> system), min to max instead often freezes everything (and I'm undervolted,
> so virtually less stable).
>
>

Some of the problems refereed to in this thread are likely hardware related,
may occur with all CPU's where voltage/frequency is scaled and are more 
pronounced with high-power CPUs such as PIII, Duron and up.

On power supplies
-----------------
Computer power supplies generally use buck type regulators where a choke
is in series with the output and is somewhat slow in regulation.
Further, modern mainboards core-voltage (also buck) regulator is electrically 
in series with the (mostly 12V)  output of the main PSU. When powersupplies 
are heavily loaded with several disks and an "oversize/upgraded"  main board,
regulation becomes marginal.

Inner resistance increases and regulation deteriorates with age as capacitors 
"dry out" and loose a substantial part of their capacity. 

The 10$ 300W PSU is a poor joke. Using a quality and even oversize powersupply 
is better for regulation, brownout protection and system stability. Saving a 
few bucks here is not worthwhile ;). BTW, a decent 300W PSU is much heavier than
the 10$ version.

On notebooks, when batteries a low/older, inner resistance is higher leading 
to similar problems with "Bigger CPUs" such as reset prior to low-charge 
shutdown.

On scaling CPU frequency/core voltage
-------------------------------------
Be warned: Semiconductors exhibit a disproportional (exponential to
avalanche) relationship between voltage and stress/~reliability. 

When switching  max to min, voltages will _overshoot_, possibly crashing and 
in extreme cases even damaging/destroying the CPU as the CPU core voltage is  
already high (close to the limit) at that time. Voltage overshoot is also 
bad for other parts of the system and unfortunately does not trigger any 
warning. I am not aware of crowbar protected Vcore on mainboards.

When switching min to max, voltages will _collapse_ very likely leading to 
a crash, and possibly even triggering the undervoltage circuit in the 
main power supply leading to a reset.

Switching speeds should be done incrementally, with a few (2-10) ms
between steps. Taking longer won't do any harm. 

The actual minimum time between steps depends on systems design and can 
only be established by watching the (core) voltage on an oscilloscope 
while modulating cpufreq/ACPI settings. The time used should be double 
or triple the minimum for longterm stability. It would be better if 
Mainboard manufacturers would specify this minimum time.

Would one want to make the interstep time userspace selectable from 1 - 50 ms?

Regards
Michael

-- 
Powered by linux-2.5.74-mm1. Compiled with gcc-2.95-3 - mature and rock solid

My current linux related activities:
- 2.5 yenta_socket testing
- Test development and testing of swsusp and ACPI S3
- Everyday usage of 2.5 kernel

More info on 2.5 kernel: http://www.codemonkey.org.uk/post-halloween-2.5.txt

Re: Cpufreq: powernow-k7 weirdness

[Juliusz Chroboczek]

>> Running stock 2.5.73 (ACPI + preempt) on a Compaq Presario 711, CPU is
>> a 950MHz mobile Duron.  I'm getting unexpected timings when enabling
>> cpufreq.

> There is a little bug in powernow-k7.c

> ducrot@neptune $  cvs diff -u -r1.42 powernow-k7.c

Yep, that did it.  Thanks a lot.

Why don't you push it into 2.5?

                                        Juliusz

Re: Cpufreq: powernow-k7 weirdness

[Ducrot Bruno]

> The actual minimum time between steps depends on systems design and can 
> only be established by watching the (core) voltage on an oscilloscope 
> while modulating cpufreq/ACPI settings. The time used should be double 
> or triple the minimum for longterm stability. It would be better if 
> Mainboard manufacturers would specify this minimum time.

That is suposed to be done via a BIOS table (with signature
AMDK7PNOW!) for the powernow-k7 driver, but is used for the
CPU only (I believe), and I guess that anyway this occur
only when a valid core voltage is applied to the CPU (well,
I hope).
But perhaps this table do not give appropriate values on some system?

Actually, I was wondering why the _PSS method (from ACPI) give
a settling time of 125us, instead of 100us for some systems.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: Cpufreq: powernow-k7 weirdness

[Ducrot Bruno]

On Mon, Jul 07, 2003 at 02:58:37PM +0200, Juliusz Chroboczek wrote:
> >> Running stock 2.5.73 (ACPI + preempt) on a Compaq Presario 711, CPU is
> >> a 950MHz mobile Duron.  I'm getting unexpected timings when enabling
> >> cpufreq.
> 
> > There is a little bug in powernow-k7.c
> 
> > ducrot@neptune $  cvs diff -u -r1.42 powernow-k7.c
> 
> Yep, that did it.  Thanks a lot.
> 
> Why don't you push it into 2.5?

Well, I supposed it was in linus bk tree.  I will report then.

Cheers,

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: Cpufreq: powernow-k7 weirdness

[Michael Frank]

On Monday 07 July 2003 21:12, Ducrot Bruno wrote:
> > The actual minimum time between steps depends on systems design and can
> > only be established by watching the (core) voltage on an oscilloscope
> > while modulating cpufreq/ACPI settings. The time used should be double
> > or triple the minimum for longterm stability. It would be better if
> > Mainboard manufacturers would specify this minimum time.
>
> That is suposed to be done via a BIOS table (with signature
> AMDK7PNOW!) for the powernow-k7 driver, but is used for the
> CPU only (I believe), and I guess that anyway this occur
> only when a valid core voltage is applied to the CPU (well,
> I hope).
> But perhaps this table do not give appropriate values on some system?
>
> Actually, I was wondering why the _PSS method (from ACPI) give
> a settling time of 125us, instead of 100us for some systems.

100us vs 125us won't matter unless the margin is too small already.

I don't know anything about the big CPU chip requirements as I have 
never read a datasheet  on on those big beasts.

My comments were related to the (analog side of the) power supply
limitations. 

IMHO mainboard Vcore switchers could do a step in 100us or so, or full scale 
over 10 steps or so, (weaker) main power supplies would likely have trouble 
as their switching frequency is much lower. Perhaps a mainboard designer
could comment?

Regards
Michael


-- 
Powered by linux-2.5.74-mm1. Compiled with gcc-2.95-3 - mature and rock solid

My current linux related activities:
- 2.5 yenta_socket testing
- Test development and testing of swsusp and ACPI S3
- Everyday usage of 2.5 kernel

More info on 2.5 kernel: http://www.codemonkey.org.uk/post-halloween-2.5.txt

Re: Cpufreq: powernow-k7 weirdness

[Daniel Thor Kristjansson]

I'm not a mainboard designer but I play one on TV...

1/ I have had two laptops from Sony's FX series and the later
   one required three times as much power, but had the same
   power supply, regulator and batteries.

2/ An EE friend of mine worked at a large computer maker and complained
   bitterly about designers just cut-n-pasting power supplies and
   regulators from older designs that had very different power
   requirements.

I wouldn't be too surprised if a lot of laptops have underpowered power
supplies. It would be better to give a large timing leeway by default,
but expose a mechanism for speeding the switching up in the /sys
filesystem.

Is it possible to do the speed change seperately from the voltage
scaling? Perhaps when slowing down the CPU, you can slow it down
immediately, then slowly scale the voltage down. You might also be able
to scale up the voltage quicker if you do it independently of the
frequency scaling. A higher frequency is going to lead to the CPU
drawing more current, It might be better to first charge up the
capacitors at the new higher voltage so they work for you instead of
against you.

Ok, I'll go back to lurking..

-- Daniel
  << When truth is outlawed; only outlaws will tell the truth. >> - RLiegh

On Mon, 7 Jul 2003, Michael Frank wrote:

]On Monday 07 July 2003 21:12, Ducrot Bruno wrote:
]> > The actual minimum time between steps depends on systems design and can
]> > only be established by watching the (core) voltage on an oscilloscope
]> > while modulating cpufreq/ACPI settings. The time used should be double
]> > or triple the minimum for longterm stability. It would be better if
]> > Mainboard manufacturers would specify this minimum time.
]>
]> That is suposed to be done via a BIOS table (with signature
]> AMDK7PNOW!) for the powernow-k7 driver, but is used for the
]> CPU only (I believe), and I guess that anyway this occur
]> only when a valid core voltage is applied to the CPU (well,
]> I hope).
]> But perhaps this table do not give appropriate values on some system?
]>
]> Actually, I was wondering why the _PSS method (from ACPI) give
]> a settling time of 125us, instead of 100us for some systems.
]
]100us vs 125us won't matter unless the margin is too small already.
]
]I don't know anything about the big CPU chip requirements as I have
]never read a datasheet  on on those big beasts.
]
]My comments were related to the (analog side of the) power supply
]limitations.
]
]IMHO mainboard Vcore switchers could do a step in 100us or so, or full scale
]over 10 steps or so, (weaker) main power supplies would likely have trouble
]as their switching frequency is much lower. Perhaps a mainboard designer
]could comment?
]
]Regards
]Michael
]
]
]

Re: Cpufreq: powernow-k7 weirdness

[Dave Jones]

On Mon, Jul 07, 2003 at 03:32:40PM +0200, Ducrot Bruno wrote:
 > On Mon, Jul 07, 2003 at 02:58:37PM +0200, Juliusz Chroboczek wrote:
 > > >> Running stock 2.5.73 (ACPI + preempt) on a Compaq Presario 711, CPU is
 > > >> a 950MHz mobile Duron.  I'm getting unexpected timings when enabling
 > > >> cpufreq.
 > > 
 > > > There is a little bug in powernow-k7.c
 > > 
 > > > ducrot@neptune $  cvs diff -u -r1.42 powernow-k7.c
 > > 
 > > Yep, that did it.  Thanks a lot.
 > > 
 > > Why don't you push it into 2.5?
 > 
 > Well, I supposed it was in linus bk tree.  I will report then.

It's in my cpufreq bitkeeper tree waiting for Linus to pull
from for about a week. I've been a little preoccupied this weekend
getting married, so I'll ask him to pull when I get back.

        Dave

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