Falcosoft wrote on 2024-03-25, 11:17:

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:
software_pstates.png

Well, it's not as what you speculated. The program had implemented both software and hardware p-state numbering. It first reads the PSTATE_STATUS msr (MSRC001_0063) to find out the current software p-state number (current_pstate). Then physical msr number = (MSRC001_0064 + number_of_boost_states + current_pstate). Then it checks whether current_pstate is 0, and if so, toggle the TSC bit in HWCR msr.

kalohimal wrote on 2024-03-25, 14:26:

Falcosoft wrote on 2024-03-25, 11:17:

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:
software_pstates.png

Well, it's not as what you speculated. The program had implemented both software and hardware p-state numbering. It first reads the PSTATE_STATUS msr (MSRC001_0063) to find out the current software p-state number (current_pstate). Then physical msr number = (MSRC001_0064 + number_of_boost_states + current_pstate). Then it checks whether current_pstate is 0, and if so, toggle the TSC bit in HWCR msr.

OK, but then I would like to report that it does not work on my system with enabled boost 😀
Can I give you any debug output for troubleshooting?

Please see one post above... (last post on page 12)

Screenshots from the following would be helpful:
cpuspd pa
cpuspd d p

I suspect "number_of_boost_states" might be the culprit for your cpu. If this value is 0 instead of 1 then we'll have the exact problem as you described.
This value is read from PCI config register, so perhaps family 10h and 15h has different register for this value? I'll check the docs when I have time.

kalohimal wrote on 2024-03-25, 14:32:

Please see one post above... (last post on page 12) […]
Show full quote

Please see one post above... (last post on page 12)

Screenshots from the following would be helpful:
cpuspd pa
cpuspd d p

I suspect "number_of_boost_states" might be the culprit for your cpu. If this value is 0 instead of 1 then we'll have the exact problem as you described.
This value is read from PCI config register, so perhaps family 10h and 15h has different register for this value? I'll check the docs when I have time.

OK, here is screenshot about the above command's output:

And also here is a test video about what is happening (sorry for the shaky video, it was made with a mobile phone):
https://youtu.be/vK0bTlaMFII

@EDit:
And here is the output of the commands when boost is disabled ( and everything is working perfectly):

From the screenshot, number of boost states is 0, so there is no boosted p-states, and P0 is the first physical msr. It is not one boosted p-state like you mentioned. Btw so far I've not seen any K10 family cpu where the motherboard BIOS will setup boost states...

Anyway please try again with these commands:
cpuspd pa
cpuspd d pm000422 pa

The second command will show whether changes to p0 is indeed registered, and also the debug info for cps (current p-state) and nbs (number of boost states).

kalohimal wrote on 2024-03-25, 15:17:

From the screenshot, number of boost states is 0, so there is no boosted p-states, and P0 is the first physical msr. It is not o […]
Show full quote

From the screenshot, number of boost states is 0, so there is no boosted p-states, and P0 is the first physical msr. It is not one boosted p-state like you mentioned. Btw so far I've not seen any K10 family cpu where the motherboard BIOS will setup boost states...

Anyway please try again with these commands:
cpuspd pa
cpuspd d pm000422 pa

The second command will show whether changes to p0 is indeed registered, and also the debug info for cps (current p-state) and nbs (number of boost states).

OK, here is the requested screenshot:

BTW, I have attached the screenshot of the non-boosted state to the end of my previous post (when everything is working perfectly).
So the point is that when boost is disbled in BIOS then eveything is working perfectly. When boost is enabled in BIOS then pm (f, etc.) command itself does nothing (as you can see in the video). You also have to set the required pmxxyyzz value to the higher P1 state and then you have to select the P0 state again in order changes to take effect.

Ok, the problem is as what I suspected earlier, that nbs (number of boost states) is reported as 0 when it is supposed to be 1, even when you enabled it in the BIOS.

This value is taken from PCI bus 0 device 18h function 4, register 15Ch, bit 2 (AMD 31116 Rev 3.62 - January 11, 2013, p.350). If this value is incorrect then we'll have a problem. According to AMD doc, register 15Ch is only valid for cpu revision E. Any earlier revision and this register will be "reserved", meaning it will be 0 when read.

Could you check the revision of your cpu please? Perhaps using cpuspd i. From the list of Thuban Phenom II cpus, all of them should be stepping E0, which is strange...

kalohimal wrote on 2024-03-25, 15:49:

Ok, the problem is as what I suspected earlier, that nbs (number of boost states) is reported as 0 when it is supposed to be 1, even when you enabled it in the BIOS.

This value is taken from PCI bus 0 device 18h function 4, register 15Ch, bit 2 (AMD 31116 Rev 3.62 - January 11, 2013, p.350). If this value is incorrect then we'll have a problem. According to AMD doc, register 15Ch is only valid for cpu revision E. Any earlier revision and this register will be "reserved", meaning it will be 0 when read.

Could you check the revision of your cpu please? Perhaps using cpuspd i. From the list of Thuban Phenom II cpus, all of them should be stepping E0, which is strange...

Hi,
My CPU revision is PH-E0 as reported by CPU-Z:

I have a BIOS guide for AMD Family 10h propcessors. It states that boost is enabled when (page 52):

CPB is enabled if all of the following conditions are true: • F3xA8[CacheFlushPopDownEn] = 1. • F3x188[EnStpGntOnFlushMaskWakeu […]
Show full quote

CPB is enabled if all of the following conditions are true:
• F3xA8[CacheFlushPopDownEn] = 1.
• F3x188[EnStpGntOnFlushMaskWakeup] = 1.
• F4x15C[BoostSrc] = 11b.
• F4x15C[NumBoostStates] = 1.
• F4x16C[CstateCnt] != 0h.
• MSRC001_0015[CpbDis] = 0 for all cores.

So it seems the same bits you mentioned have to be set but other condiditons also have to be met. Yet, the real world situation is that CPB is enabled (at least the CPU behaves according to the enabled state) but the bits are not set by my BIOS...

BTW, in case of my BIOS this is the only setting I change when I get the different results shown on the screenshots:

Yes, that's the doc I am referring to all along, Rev 3.62.

The BIOS had turned on CPB in the cpu, and should set the following to 1, but instead it remains as 0:
F4x15C[NumBoostStates] = 1
This is the "PCI bus 0 device 18h function 4, register 15Ch, bit 2" I was referring to previously.

So we've found a bug in the BIOS of your motherboard. Perhaps you could check whether there is any update available? Otherwise there is nothing much we could do, except to disable it in the BIOS.

kalohimal wrote on 2024-03-25, 16:24:

Yes, that's the doc I am referring to all along, Rev 3.62. […]
Show full quote

Yes, that's the doc I am referring to all along, Rev 3.62.

The BIOS had turned on CPB in the cpu, and should set the following to 1, but instead it remains as 0:
F4x15C[NumBoostStates] = 1
This is the "PCI bus 0 device 18h function 4, register 15Ch, bit 2" I was referring to previously.

So we've found a bug in the BIOS of your motherboard. Perhaps you could check whether there is any update available? Otherwise there is nothing much we could do, except to disable it in the BIOS.

So it seems the same bits you mentioned have to be set but other condiditons also have to be met. Yet, the real world situation is that CPB is enabled (at least the CPU behaves according to the enabled state) but the bits are not set by my BIOS.
The strange thing is that CPB and boosted state works perfectly in Windows when enabled in the BIOS.
This is the latest BIOS for my board and actually the only one that supports Thuban (F7D).
https://www.gigabyte.com/Motherboard/GA-MA790 … ort#support-cpu

This is just a theoretical problem anyway since I use my Phenom II without boost enabled all the time. I have just checked CPB since you explicitly mentioned it in the new version of CpuSpd.

One way I can think of to bypass this issue is to ignore F4x15C[NumBoostStates], and check for all other conditions to see whether CPB is enabled. If so then set nbs to 1, since there could only be 1 boost state for K10 cpus. But then the amount of work doesn't justify as you could simply turn it off in BIOS. It is not need in retro DOS gaming anyway.

kalohimal wrote on 2024-03-25, 16:39:

One way I can think of to bypass this issue is to ignore F4x15C[NumBoostStates], and check for all other conditions to see whether CPB is enabled. If so then set nbs to 1, since there could only be 1 boost state for K10 cpus. But then the amount of work doesn't justify as you could simply turn it off in BIOS. It is not need in retro DOS gaming anyway.

I do not think it is necessary, for me at least it's not. As you said it's not needed for DOS and for that matter even is Windows this first version of CPB is rather problematic.
It's much better to use manual clock/voltage fine tuning and P-state adjustment with the help of K10Stat.