[To all newer AMD Turion owners]Strange power handling on hp dv5

[blackshard83]

* If you are interested in TurionPowerControl program, just go at the bottom of the post *

Hi all to the forum, this is my first message here.
I posted this message on amd forums too, but got really low feedback about this. Sorry for long message, but I think the problem I found needs some explanation.

I own a HP DV5-1025el laptop with Turion Ultra ZM-80 processor and Windows Vista 32 bit, running at 2.1 Ghz. The laptop is working wonderfully and I have no stability problem at all.

Since I love to optimize my machines at maximum, I started to search some informations about Power States and such similar things, mostly to tweak and reduce battery cpu usage. I made by myself an utility to control CPU Voltage for each pstate, like PumaStateCtrl, but more flexible. It's in an early stage, but it seems to work good for ZM processors, and maybe I can post it here if someone asks.

I studied the official AMD datasheets about Turion and Turion Ultra (mainly ZM and RM series) processors and found that they have 3 active PStates (actually they have 8 pstates, 3 are activated and 5 are not). My ZM-80 has these pstates:

PState 0 - 2100 Mhz, 1.100 volt - Enabled
PState 1 - 1050 Mhz, 0.950 volt - Enabled
PState 2 - 525 Mhz, 0.800 volt -Enabled

Then there are other pstates from 3 to 7, but are disabled:
PState 3 - 1050 Mhz, 0.950 volt - Disabled
PState 4 - 800 Mhz, 1.550 volt - Disabled
PState 5 - 800 Mhz, 1.550 volt - Disabled
PState 6 - 1050 Mhz, 1.200 volt -Disabled
PState 7 - 1050 Mhz, 1.200 volt - Disabled

The issue is related to the fact I randomly see transitions to pstate 6, that is supposed to be disabled! Actually, as you can see above, pstate 6 overvolt the processor to 1.200 volt and this is a clear violation of the specifications (1.200 volt => overvolting!) , even because PState 6 is set to disabled and should not be used.

This may cause faster battery depletion, higher heat production, and maybe other serious problems with power regulation modules.

How to replicate this:
I found that this behaviour always happens when I set windows vista power profile to "Maximum Performance". Using AMD Power monitor (you can find it here) or even cpu-z I get fast transitions between PState 0 and PState 6, where there should be no transitions at all!

Who is affected:

At the moment, all Turion Ultra ZM, Turion RM series and Athlon X2 QL series processors are affected by the problem (all 65nm notebook parts), as many users reported. We have no informations about Sempron SI series at the moment.

Also it is not a problem of a specific notebook brand, but looks like a generalized problem. Users with HP and Acer notebook actually have reported the problem.

Please report your experiences, thank you and excuse for my bad english.

Possible reason:

I found that disabling OS power management (using High performance profile in Windows, or disabling or fixing cpu scaler in linux) and then forcing the processor in pstate 0 (using TurionPowerControl -fo switch) the processor to go to pstate 6 and stay there while the processor is idling. Maybe it is related to some C halt states.

Also I discovered there also some rare transitions to pstate 7 too, but these still have no apparent cause and I have no methods to artificially reproduce them.

Update:

How to almost completely solve the problem:

Launch the program with -l command like this:

TurionPowerControl -l

It will show something like this:

Turion Power States Optimization and Control - by blackshard - v0.12
Detected CPU:
Family: 0xf             Model: 0x3              Stepping: 0x1
Extended Family: 0x11   Extended Model: 0x3
Package Type: 0x2       BrandId: 0x1400
Detected Physical Cores: 2
Processor has 3 Power Planes
Detected processor: Athlon X2 QL processor
Processor has 2 cores
Processor has 8 p-states
core 0 pstate 0 - En:1 VID:40 FID:13 DID:0 Freq:2100 VCore: 1.0500
core 0 pstate 1 - En:1 VID:60 FID:13 DID:1 Freq:1050 VCore: 0.8000
core 0 pstate 2 - En:0 VID:48 FID:13 DID:1 Freq:1050 VCore: 0.9500
core 0 pstate 3 - En:0 VID:0 FID:0 DID:0 Freq:800 VCore: 1.5500
core 0 pstate 4 - En:0 VID:0 FID:0 DID:0 Freq:800 VCore: 1.5500
core 0 pstate 5 - En:0 VID:0 FID:0 DID:0 Freq:800 VCore: 1.5500
core 0 pstate 6 - En:0 VID:28 FID:13 DID:1 Freq:1050 VCore: 1.2000
core 0 pstate 7 - En:0 VID:28 FID:13 DID:1 Freq:1050 VCore: 1.2000
core 1 pstate 0 - En:1 VID:40 FID:13 DID:0 Freq:2100 VCore: 1.0500
core 1 pstate 1 - En:1 VID:60 FID:13 DID:1 Freq:1050 VCore: 0.8000
core 1 pstate 2 - En:0 VID:48 FID:13 DID:1 Freq:1050 VCore: 0.9500
core 1 pstate 3 - En:0 VID:0 FID:0 DID:0 Freq:800 VCore: 1.5500
core 1 pstate 4 - En:0 VID:0 FID:0 DID:0 Freq:800 VCore: 1.5500
core 1 pstate 5 - En:0 VID:0 FID:0 DID:0 Freq:800 VCore: 1.5500
core 1 pstate 6 - En:0 VID:28 FID:13 DID:1 Freq:1050 VCore: 1.2000
core 1 pstate 7 - En:0 VID:28 FID:13 DID:1 Freq:1050 VCore: 1.2000
Processor Maximum PState: 1
Processor Startup PState: 2

Minimum allowed VID: 52 (0.900v) - Maximum allowed VID 28 (1.200v)
Processor AltVID: 60 (0.800v)
Processor Northbridge VID: 52 (0.900v)

SMAF7 is disabled; processor is using LMM Configuration Registers for Power Mana
gement
DID to apply when in C1E state: 0

Voltage Regulator Slamming time register: 2
Voltage Regulator AltVID Slamming time register: 2
Voltage Regulator Step Up Ramp Time: 0
Voltage Regulator Step Down Ramp Time: 0
Done!

You may see at the top Core 0 PState 0, and some rows below Core1 PState 0.
Now look that Pstate 0 (both Core 0 and Core 1) has VID=40, DID=0 and FID=13 in this example.
Also look that Pstate 6 (on both cores again) has VID=28, DID=1 and FID=13

To prevent any transition to pstate 6 i found that overwriting the pstate 6 parameters with the same values just stops the transitions. Don't know why, just discovered that works! (nb: It works also if you put anything else in there, but just to be safe use the same parameters you got from the table).
So, following the example pstates table of above, I wrote:

TurionPowerControl -pallc 6 28 1 13

and there are no more transitions to pstate 6!

The same doesn't apply to pstate 7, but actually I managed to mitigate the problem with this other command (always remember to change parameters according to your pstates table):

TurionPowerControl -pallc 7 40 0 13

this actually write the values I have in pstate 0 over pstate 7, so transitions from pstate 0 to pstate 7 doesn't require stabilization time, and doesn't overvolt the processor too. Some people reported to have issues when touching pstate 7, so if your computer crashes issuing last command, just forget it: transitions to pstate 7 are much less frequent than transitions to pstate 6.

UPDATE 2010/05/28 - Some more speculation about Pstates 6/7

Hi guys, I report some news.

First, I investigated more about the pstate6/7 behaviour.
I found and report the fact that I can undervolt my processor much more with pstate 6 anomaly on than with pstate 6 anomaly fixed.

Without touching pstate 6 (so with anomaly on), I can undervolt my processor pstate 0 to 1.0375v for core 0 and 1.050v for core 1, and it's running pretty stable for some days now.

Touching pstate 6 (so with anomaly fixed) I can't go below 1.075v (for both cores) because I experience sudden crashes. The most curious thing is that I can undervolt to 1.050v or even 1.0375v: the computer will work fine for some time, but then all of a sudden I get a crash.

I'm thinking more and more about the fact that pstates 6 and 7 serves as a sort of "trampoline" to pstate0, and they just allows the voltage to ramp up just a moment before frequency goes up too, and so allow better voltage stabilization.

BTW, it looks like they produce a bit warmer processor, but actually I can't say nothing about battery life.

UPDATE 2011/07/05:

TurionPowerControl is a command line program available for Win x86, Win x64 and Linux that can be downloaded from this homepage:

TurionPowerControl Homepage

It allows to tweak VID, FID and DID of Turion ZM/RM and Athlon QL processors and now also for Phenom, Phenom II, Athlon II and Turion II processors. Also shows lots of informations about processor internals, like HTC (Hardware Thermal Control) status, HyperTransport link, power states tables and more.

Executables and source code are included.
Also for Linux there's a little script to compile the program for your specific distribution and platform (see included documentation)

I provide the older stable version (0.22) for people who can have problems with newer version. Remember that version 0.22 does not support Family 10h processors (like Phenom, Phenom II, Athlon II and Turion II), but just Family 11h processors (Turion ZM/RM and Athlon QL).
It is available here:

TurionPowerControl v0.22


MSVC Project source code (v0.12):

I also put here the whole sourcecode (and project files, version 0.12) and binaries compiled for x86 and x86-64 for Windows using Microsoft Visual Studio C++ 2008. You can grab them here:

TurionPowerControl v0.12 - MSVC Sourcecode and Project Files

[miner]

Yeah, I have noticed the spikes. Why it happens I do not know. Although in my case it happens very infrequently. I have been using Puma State Ctrl on my ZM 86 for a while now and wouldnt mind trying out yours if you have a 64bit version available.

[Evolution]

Same here, I have the same spikes on my ZM-82. I never noticed this before since I rarely use vista's high performance setting. However I would have noticed this in the past because I used RMclock on my previous TL-50; but since RMclock doesn't work with the newer AMD processors I never noticed that this overvolt was occurring.

This is probably a CPU errata.

[blackshard83]

Oh thanks god someone replied

Unfortunately I have no 64bit version available at the moment, but I'm planning to a build a specific version as soon as possible, and maybe post here a copy of both 32 bit and 64 bit versions.
It would be nice if some people with RM and QL processors show up here, because I would add specific support for those processors too (actually official support is just for ZM processors).

About the spikes, I got tons of them when power profile is set to maximum performance. Actually I don't like them at all, I really can't get used to the fact that my processor goes overvolted and they caused me some issues with low latency asio-based audio software (like buffer underruns with fruityloops).

I noticed too that if I touch any of the pstate 6 parameters (VID, DID or FID) with my program, those spikes and transitions to pstate 6 just stops and the processor goes to behave like specifications say.

[blackshard83]

Originally Posted by Evolution

Same here, I have the same spikes on my ZM-82. I never noticed this before since I rarely use vista's high performance setting. However I would have noticed this in the past because I used RMclock on my previous TL-50; but since RMclock doesn't work with the newer AMD processors I never noticed that this overvolt was occurring.

This is probably a CPU errata.

Well, they happen even when power profile is set to balanced. It looks like they happen when entering/exiting fastest pstate 0.

[Evolution]

I also notice a slight overclock when the CPU is running at maximum speed and under heavy load. For instance sometimes it goes beyond 2200mhz once it almost reached 2300mhz, could this be the possible reason for the overvolt.

Anyway I haven't seen this overvolt phenomenon on anything other than the high performance setting so far; for me it hasn't occurred when I am running in the power saver or balanced setting(atleast I haven't seen it during my monitoring so far). I really have a strong feeling this is a cpu errata.

[2.0™]

It might just be an error with the AMD power monitor program as CPU-Z doesn't report 1.2v for my ZM-80.

I have top voltage set @ 1.012V using pumastatectrl. CPU-Z reports at as 1.012V while AMD power monitor reports an flip-flop of 1.013V and 1.200V.

My High performance Processor state setting is 100% min/100% max for plugged in.

[blackshard83]

Well actually I don't think it is a power monitor mistake. CPU-Z has a much slower update rate, but on my machine it still reports 1.200 volt sometimes.

To be sure about readings I made a monitoring feature in my software that tracks realtime pstate changes asking directly to the processor's Machine State Registers every 50ms and registers transistion to other pstates than 0, 1 and 2. A one minute monitoring reports this:

Turion Power States Optimization and Control - by blackshard
Detected CPU:
Family: 0xf             Model: 0x3              Stepping: 0x1
Extended Family: 0x11   Extended Model: 0x3
Processor has 3 Power Planes
Monitoring...
pstates:6
Detected pstate 6 on core 0
pstates:1 6
Detected pstate 6 on core 1
pstates:1 6
Detected pstate 6 on core 1
pstates:2 6
Detected pstate 6 on core 1
pstates:1 6
Detected pstate 6 on core 1
pstates:2 6
Detected pstate 6 on core 1
pstates:2 6
Detected pstate 6 on core 1
pstates:1 6
Detected pstate 6 on core 1
pstates:1 6
Detected pstate 6 on core 1
pstates:2 2 ^C

Attached to this post there's the application for Win32 targets. It requires admin privileges and visual studio 2008 runtimes.
Trying to launch the app without any flag shows accepted command switches.
Launching the app with -CM will start monitoring sequence (use CTRL+C to terminate the session), while using -l switch will show pstates table.

[2.0™]

I can't get CPU-z to report the 1.2V in high performance mode. But the AMD power monitor flip-flops between 1.012v and 1.2v a few times a second.

Here's something interesting though; loading the CPU to 100% utilization using wprime, the voltage caps @ 1.013V and never peaks into 1.2V as according to AMD power monitor.

Same if I set wprime to 1 thread.

Playing an MP3 or video through Win Media 11, the frequency of crossing into 1.2V is reduced.

Running an anti-virus scan with a sustained CPU utilization rate above 33% also prevented the voltage from crossing into pstate6, 1.2V. Same with doodling in ArtRage which while doodling maintains a CPU utilization rate above 33%.

So I suppose the conclusion is that it only goes into P-state6 (1.2V) at relative idle and not under any appreciable load. Must be by design.

I wonder if those who have not undervolted experience this jump to 1.2v, Pstate 6?

[blackshard83]

Yes, exactly same to me, with and without undervolting: they are much frequent when idling.
AMD Power monitor shows also frequency switching from 2100 to 1050 Mhz

If you can run my program above, fire this command:

> turionpowercontrol -pallc 6 48 1 13

In my experience it stops transitions to pstate 6 immediately just by overwriting pstate 6 vid, fid and did.

Maybe try also

> turionpowercontrol -CM

It shows to me some transitions to pstate 7 too

edit: since I don't know your processor model