kalohimal wrote on 2024-02-13, 02:57:

Fair enough and thanks for sharing. But unfortunately I simply do not have the time nor interest to dwell on this further. As already mentioned I've previously experimented and found changing the BSP alone won't do the trick, at least not on the CPU I tested. I'd rather stick with what AMD docs said, than depending on undocumented functions that might not work across all CPU revisions, and have people coming with issues and creating lots of headaches that need fixing later. Good day and have fun.

It's OK. And of course you were right that you decided to do settings according to documentation. What you achieved with AP programming under DOS is exceptional as I have already mentioned before. So you have done the best with using it to set Core 2/K10 MSRs.
I have just mentioned that in reality things are different and in case of K10 this is not strictly required .That's all.
Bye.

@Falcosoft

No worries my friend, your good intention is understood. Cheers.

Just wanted to say, thank you so much kalohimal for creating such a great tool, really appreciate the effort!
I'm using it on my K6-III+ build and soon enough I will give it a go in a new C3 Nehemiah set up I'm working on.

Thanks!

I'm not into low-level hardware programming (BIOS, drivers etc. assembly related stuff), but for some time I've been wondering if it is possible to be written some kind of driver or DOS TSR for AMD K6-2+/III+ processors, that can automatically change CPU's multiplier according to its usage/load? As far as I know these "+" versions are mobile variants of the К6-III with implemented some basic power saving features. So far I haven't been able to find such driver or software tool for DOS or win 9x/Me/XP/NT for those latest K6 processors.

I apologize that my question is a bit off-topic, but SpuSpd tool does support manual setting of K6-2+/III+ multipliers.

@kahuna

Thanks and appreciate that.

@analog_programmer

Yes that could be done, in fact many years ago I had come across such a utility (a TSR to gather cpu execution statistics). Unfortunately I could not recall the utility's name. AFAIK how modern OSes calculate cpu load is by checking the frequency and time the cpu spent on idling. And DOS does have an "idle hook" (INT 28h, Idle Interrupt) which is called when DOS has nothing to do. So if your TSR program hooks on to this, gathers cpu statistics and then change the multiplier, then yeah theoretically you could achieve what you're asking.

cpuspd works brilliantly on my kt133a/686b system, but i'm not having success on a i440bx/piix4 laptop. it's a compaq armada e500 with a p3 850mhz. there's no acpi option in the barebones bios, but xp installs in acpi mode instead of apm so i assume there's no issue there.

enabling/disabling the cpu caches works fine, but none of the granular t (1-8) parameters has any effect on system performance (benchmarked with topbench). cpuspd reports no error and it registers the previous t (1-8) setting on subsequent runs as if it was always successful.

the cpuspd chart indicates my system should be supported so what's going wrong?

@stanwebber,

Could you issue these 2 commands and show the screenshot please:
cpuspd ip
cpuspd d t

The first one will perform a PCI scan and list all PCI devices. This will show us the south bridge in your laptop (most probably a PIIX4M).

Second one will just show the debug messages for detecting ACPI and let us know whether the ACPI tables are setup by BIOS (without which the program won't be able to find the throttle port). Since you could set the throttle using t[x] and the program didn't complain about it, I doubt it is the problem but we'll take a look anyway.

kalohimal wrote on 2024-03-14, 18:42:

@stanwebber, […]
Show full quote

@stanwebber,

Could you issue these 2 commands and show the screenshot please:
cpuspd ip
cpuspd d t

per your request:

cpuspd ip

1CPUSPEED version 2.1 - by David C.Y. Wong.
2           Vendor:   Class:
3Bus Dev Fn Device ID Subcls Description
4--- --- -- --------- ------ ---------------------------------
5  0   0  0 8086:7190  6:0   Host bridge
6  0   1  0 8086:7191  6:4   PCI-PCI bridge
7  0   4  0 104C:AC1C  6:7   CardBus bridge
8  0   4  1 104C:AC1C  6:7   CardBus bridge
9  0   7  0 8086:7110  6:128 Other bridge
10  0   7  1 8086:7111  1:1   IDE disk controller
11  0   7  2 8086:7112 12:3   USB serial bus controller
12  0   7  3 8086:7113  6:128 Other bridge
13  0   8  0 125D:1978  4:1   Multimedia audio multimedia controller
14  0   9  0 8086:1229  2:0   Ethernet network controller
15  0   9  1 11C1:0445  7:0   Serial communications device
16  1   0  0 1002:4C4D  3:0   VGA display controller

cpuspd d t

1CPUSPEED version 2.1 - by David C.Y. Wong.
2DPMI version: 0.90 flags: 01
3acpi_search_rsdptr: ebda addr = 20F0
4acpi_search_rsdptr: found in bios, rsdtPtr = FFF476D
5Found RSDT, length = 44, entries = 2
6  addr[0]: FFF4828, table: FACP
7  addr[1]: FFF4799, table: SSDT
8ACPI found, RSDT: 0FFF476D, FADT: 0FFF4828, DSDT: 0FFF48A0
9Throttle register: 3000
10Throttle port: 5010h, 3 bits, offset: 1
11CPU throttle is 8/8

Your screenshots look normal:

8086:7110 -- this is the PIIX4/E/M south bridge
8086:7113 -- this is the power management device

And as expected the ACPI tables are present in the BIOS as well so no problem there.

Could you try this please:
cpuspd t tx1
and check whether the throttle changes using a speed benchmark program. The first 't' is needed to setup the ports and the 'x' in second 'tx' will force enabling the clock control bit in the PIIX4. '1' could be any throttle values you like (except 8 of course).

You could also try forcing the program to use the south bridge database file "cpuspd.sbi" instead:
cpuspd xp t1
Please note that the 'xp' command is experimental (leading 'x') and might be removed in future revision. I should probably move this to a proper throttle command in the next revision.

Ok I dug out my old and trusty Asus P2B-VM with PIIX4E, tested and confirmed there is a bug.

cpuspd t1 <== this would set the throttle value but the throttle didn't happen.
cpuspd t tx1 <== this works
cpuspd xp t1 <== this works as well

The PIIX4E has an extra "clock control enable" bit which need to be set to enable power management, when compare to other later Intel south bridges. I've looked at the code and yeah, in the first case the function that set this bit wasn't called. I'll fix this in the next revision. Meanwhile, please use "t tx" as an interim solution. Also, once this clock control bit is set, you don't need to set it again until the next reset, so subsequently "cpuspd t[1..8]" will work.

I believe your test results would be the same since the registers are the same for PIIX4E and PIIX4M. Please let me know if otherwise. Cheers.

yes, i tested the same scenarios on my laptop and the behavior is identical to what you ascribe. given the plethora of 440bx systems i'm surprised this hasn't come up before. cpuspd has no software equal in slowdown smoothness (especially on via systems). i look forward to the next version release.

Dear all,

I have been playing around with cpuspd 2.1 on my new build based on a VIA C3 Nehemiah 1200MHz (9x 133 MHz) processor.
Below these lines you could find the speed sweet spots I consider the best ones.

I do not like using "throttle" as I believe it makes things sound or behave weird, so all these results are without toggling the default throttle value (8 for this CPU).
I have also used smb from RayeR to adjust the FSB speed.

Please note, I tried to disable D-Cache but that resulted in freezes (post below).

At any rate I hope this helps someone!
Thanks again Kalohimal for such a great tool.

I just found a quirk. Not sure if it has been reported yet.
If I disable D-Cache (ecd), the CPU runs at such new speed. However, I cannot run cpuspd again, otherwise my system freezes 🙁

Edit to say that is not a quirk, it's an important issue. I thought it was fine because I could run 3dbench without problems, but I just tried to launch 'edit' with D-Cache disabled, the machine freezes 😢
Also tried to launch Doom with the D-Cache disabled, I got right away an EMM386 unrecoverable error and had to reboot.

Another edit as I've run a couple of commands with the debug flag.

cpuspd d i
DPMI version: 0.90 flags:01
VIA Nehemiah ID(6,9,A)
CPU fequency is 1200MHz (TSC)
CPUID.1 ebx=00000000 ecx=00000000 edx=0381B93F flag=0007

cpuspd d ecd
DPMI version: 0.90 flags:01
VIA set features: eax=9e3f1ad6,9e3f5ad6
Cache is on, L2 cache is on
VIA I-cache: on, D-cache: off, branch prediction: on
VIA show features: eax=9e3f5ad6

Apologies for the multiple edits, just wanted to provide all information I can without spamming too much.

@kahuna,

I tested on my C7 Esther and speed600/doom did hang when ecd is set (D-cache disabled) alone. But it seems to work fine when c2d is issued first:

cpuspd c2d ecd

From previous testing it seems that Ezra has no problem since no one reported any problems, so perhaps it no longer works from Nehemiah onwards? I have neither Azra nor Nehemiah so I can't make any confirmation. Or is it because the D-cache resides in L1, it needs L2 to be off? I don't know. The datasheet from VIA is quite brief on the programming section and mentioned only which bit on which MSR to toggle, so all the program does is just toggle that particular bit. Currently I have no further solution for this problem.

It works! 😀

Disabling L2 first and then disabling D-Cache does the trick.
I thought I tried that but maybe not in that order, not sure.
Anyway, I’ll test more later tonight and update the table accordingly.

Thank you so much!

I have been testing different things, and folks this is awesome! 😎 cpuspd is amazing!! 😁
RayeR's SMB also helps too! 😀

Here is the final table I came up with for my VIA C3 Nehemiah 1200MHz.

Enjoy!

Version 2.2 released. Please download from post #1.

What's new:

• Bug fix for PIIX4 "clock control enable" not set in throttle.
• Improved SMP codes to better support AMD K10 cpu (and beyond).
• Improved robustness of ACPI search codes which will hopefully eliminate protection faults reported for some motherboards.
• Improved p-state functions to respect boosted p-states for AMD K10 (and perhaps future AMD cpu families).
• Correctly report error when CPU doesn't support hardware p-state (HWP).
• Cleanup VIA Esther codes.
• Multiplier (m) and fidvid (f) commands now works for AMD K10.
• Added FDV (Fid, Did, Vid) values display for the 'p' command for AMD K10.
• Added 'pe' command for AMD K10, to allow changes to Fid, Did and Vid for other p-state. (Note: I'd forgotten to include this in the readme.txt and the program's help. Will do that in the next version, but for now this command will work.)
• Added 'pf' command for AMD K10, to allow changes to Fid and Did only without affecting Vid.
• Added 'tf' command to use the south bridge database file 'cpuspd.sbi' first before attempting ACPI search for throttling. Normally the program will first attempt to use ACPI to find the throttle port, and switch over to the database file only when ACPI search failed.

The 'm' and 'f' commands work as previously, i.e. m[x] sets the multiplier in decimal, and f[ffvv] sets the fidvid (ffvv is 4 digit hex value, where ff = fid and vv = vid).
cpuspd m12 <-- sets multiplier to 12.
cpuspd f040C < -- sets fidvid to fid=04 and vid=0C.

The 'tf' command is identical to 't', except for using the database file:
cpuspd tf <-- shows current throttle, but setup throttle port using database file instead of ACPI.
cpuspd tf4 <-- sets throttle to 4, but setup throttle port using database file instead of ACPI.

Note: the ‘min' and 'max' are values reported by the cpu. Since K10 is not locked, it is possible to set values beyond 'max' (overclocking/overvoltaging).
Important note: Changing Vid is risky as severe over voltage might damage the cpu. For K10 the Vid value is inversely related to voltage, i.e. smaller Vid results in higher voltage!

'cpuspd p' will now display the FDV value (Fid, Did, Vid), to provide this information at a glance (please see picture below).
How to use 'pf' command:
pf[ffdd] - modify the Fid (frequency multiplier) and Did (frequency divisor) for the current p-state, leaving Vid alone. ff = Fid and dd = Did in hex. ffdd must be 4 digit hex.
For example:
cpuspd pf0604 < -- will set multiplier to 6 and divisor to 4.

How to use 'pe' command:
pe[nffddvv] - modify the Fid (frequency multiplier), Did (frequency divisor), and Vid (voltage) for the specified p-state. n=p-state number to change, ff = Fid, dd = Did, and vv = Vid in hex. nffddvv must be 7 digit hex.
For example:
cpuspd pe206040C < -- will set p-state P2's multiplier to 6, divisor to 4, and voltage to 0C.

Commands that are no longer needed and removed: tx, xp

Cheers and have fun.

kalohimal wrote on 2024-03-24, 14:50:

..
[*]Improved p-state functions to respect boosted p-states for AMD K10 (and perhaps future AMD cpu families).
...

Hi,
I have tested this with a Thuban Phenom II and enabled core performance boost. It does not work as expected. In case of enabled boost and Thuban Phenom II the real P0-state becomes the boost state and you cannot select boost state (P0) directly anymore only P1 and higher P-sates stay directly selected. So in CpuSpd there will be a +1 offset effective all the time between the P-state you set and the P-state you select. The result is that none of the -pm, -f etc. commands will work anymore since they change another MSR than the real active one.
You have to set a higher numbered P-state and then you have to select a -1 lower P-state in order to activate the settings that the -pm, -f etc. commands have set.
Currently with activated boost I have to run the following 4 commands (in this order) to get the same effect that normally (without boost enabled) only 1 command can achieve:

1//REM for 100 MHz
2cpuspd p1
3cpuspd pm000425
4cpuspd p0
5cpuspd pm000425 // this is needed to reset TSC since currenly TSC is only reset when P0 state is set however with enabled boost really P1 is the lowest selectable P-state

Overall the problem seems to be that the set routines always use 'hardware' P-state numbering but the select routines use 'software' P-state numbering. In case of older Phenoms and Thuban with disabled boost there is no difference between the 2 numbering systems. But with enabled boost on Thuban there is an offset (1) between the 2 numbering systems:

@Falcosoft,

Thanks for reporting the problem. Could you provide a p-states listing please?
cpuspd pa
And also,
cpuspd d p

On my Gigabyte GA-78LMT-S2 with FX-4300, the boosted p-states are working as expected:

Here there are 2 boosted p-states, b0 & b1 (b indicates boost state). Current p-state is 0* (* indicates the current p-state), and the BIOS had set it up in the 3rd p-state register (MSRC001_0066, with MSRC001_0064 & 65 being the boosted p-states). Changing current p-state with cpuspd pm10040f changed P0 correctly, as shown in the screenshot below:

The only issue is the frequency is not linked correctly to TSC, I'm not sure why this is so. AMD's doc said it uses "software p-state" (31116 Rev 3.62 - January 11, 2013, p. 419), and in this case software p-state is 0 (P0), which is MSRC001_0066.

Btw there is a new command which I'd forgotten to include in the program's help and also the readme.txt. I thought it was released in the previous version but obviously I'd mistaken. With it you can change the value of any p-state:
pe[sffddvv]
where s is the p-state to modify, ffddvv is the fid, did, vid as usual. For example, to change p-state 2 to 10040f:
cpuspd pe210040f
Note that the p-state number here is the "software p-state" (per AMD doc) and not the "hardware p-state" (which is per the MSR). At the moment the program doesn't allow you to change the boost states, this is because the cpu doesn't allow a transition to a boost state under software control.