[AMD][Family 17h] Globale C-States

[cyring]

BIOS C-States option

C-STATES [OFF]
	HWCR(0xc0010015) = 0x0000000149000011
	CC6 (0xc0010296) = 0x0000000000080808
	PC6 (0xc0010292) = 0x0000000104000012
	PST (0xc0010064) = 0x8000000048D2088C
	Ratio = 45.71
	Vcore = 1.0562   1.0562   1.4812
C-STATES [ON]
	HWCR(0xc0010015) = 0x0000000149000011
	CC6 (0xc0010296) = 0x0000000000484848
	PC6 (0xc0010292) = 0x0000000104000012
	PST (0xc0010064) = 0x8000000048D2088C
	Ratio = 47.00
	Vcore = 0.9062   0.9062   1.4875

• MSR 0xc0010296 with a mask of 0x0000000000404040 seems to be the C-States enablement mode

[cyring]

CC6 activation fixed in commit 47b46d6

Vcore and Power consumed tests

• CC6 disabled
  

• CC6 enabled
  

[adatum]

CC6 disabled:

CC6 enabled:

[cyring]

CC6 disabled:

CC6 enabled:

Thanks. I clearly see the differences, especially the temperature.

[adatum]

I clearly see the differences, especially the temperature.

I expect there is a difference in temperature and power, but I wouldn't read too much into what the screenshots show.

The system was mostly idle but with browser tabs open, and the normal temperature fluctuations are greater than the average difference between the enabled/disabled states, especially with warm ambient temperatures ~30C.

I did a similarly idle test over time, and I wouldn't say that I can distinguish enabled vs disabled in the CPU temperatures. Maybe the VRM temperature shows a small and more stable difference.

[cyring]

... and I wouldn't say that I can distinguish enabled vs disabled ...

Minimum Vcore can also be observed in single user console mode.

A hardware C-state counter will be the best way to measure the idle residency; but no such register is found in Zen specs.
The ACPI space may offer a similar counter, that's a work in progress.

EDIT: I do also blacklist cpufreq drivers and idle=halt

[cyring]

As part of commit 8e4add9 , the BIOS Global C-State is reported through CoreFreq CCx

• After combinary tests, the state is enabled when the Base Address (BAR) is different from zero
• C-State BAR register is specified as read-write. I'm doing a read-only access.
  

  CoreFreq/amdmsr.h

  Line 440 in ec1c731

  unsigned long long /* Per SMT: MSR 0xC0010073 (RW) */

[cyring]

PMx07E [CStateEn] (FCH::PM::CStateEn)

C1eToC3En. Read-write. Reset: 1. 1=Put APU into C3 state in C1e state. 
C1eToC2En. Read-write. Reset: 0. 1=Put APU into C2 state in C1e state. 

As part of commit f1c0e8e , the CoreFreq Experimental mode is required to read the Power Management (PM) Registers

• Remarks:

1. Not sure if the AMD PPR is specifying UnDemotion or Auto Demotion
2. C1U (the Intel variable) is used as a placeholder for Zen C2U
3. Because C2U C3U exist, can we say than Zen C1E is de facto enabled at boot ?

[adatum]

Global C-States disabled in BIOS:

Global C-States enabled (Auto) in BIOS:

[cyring]

@adatum 👍 Thank you for your tests.
According to your screenshots, you also have tested C1U C3U which means that my assembly instructions to read the FCH did not crash the 2700X.
Removing Experimental and showing C2 UnDemotion in commit d9b2663

[adatum]

You're welcome.

One side note: using the scroll wheel up or down in the UI causes an error message which I do not know how to close:

The upper left corner shows [c306:41] on scroll wheel up, and [c306:42] on scroll wheel down.

[cyring]

One side note: using the scroll wheel up or down in the UI causes an error message which I do not know how to close:

The upper left corner shows [c306:41] on scroll wheel up, and [c306:42] on scroll wheel down.

For some reasons, a key pressed may have been injected into the UI which handled it as a command to the driver. Could have been a mouse move, mouse buttons ?
Meanwhile I will debug and harden this ...

• Writing to the FCH is now part of commit 3be3ff4
  Bellow C2U and C3U state have been toggled but I don't notice a major change in Voltage, Temps, Consumption ...
  

[cyring]

I don't know if these PM registers managed by the FCH are SMT or per Core or CCX or whole Package ?

Current implementation in driver: any CPU is reading / writing through the FCH; and no access protection of mutex, semaphore kinds, is applying.

[adatum]

For some reasons, a key pressed may have been injected into the UI which handled it as a command to the driver. Could have been a mouse move, mouse buttons ?

Yes, mouse scroll wheel, up and down.

[cyring]

For some reasons, a key pressed may have been injected into the UI which handled it as a command to the driver. Could have been a mouse move, mouse buttons ?

Yes, mouse scroll wheel, up and down.

Do you get the same in a plain shell terminal or console ?
Can you read the ASCII dump of those mouse events ?

EDIT: here's a program I did to dump keys
Get source at https://github.com/cyring/Tips/blob/master/C/getkey.c

cc getkey.c -o getkey
./getkey 

Press [Escape] to quit or type any key or mouse events to dump the ASCII codes

EDIT: My mouse middle button is also pasting whatever buffered characters into the_CoreFreq_ UI which just believes they are User inputs !
I'm not sure I can manage this. The UI is acting like a shell.

[cyring]

Depending on the number of characters pasted, you will have to escape many times the Driver message in red until the exchange ring gets empty (at most 16 commands)

[adatum]

No I don't get issues in a plain shell terminal.
I tried the getkey.c program, but scrolling does not register as an input and just scrolls the terminal window as normal.
I tried xev which does register events from the scroll wheel but I don't know if any of the output are ASCII codes.

You're right, pressing [Escape] enough times finally gets rid of the red Driver message.
I realized that mouse wheel scrolling does not always cause the error. At some times it is taken as user input, for example opening a menu or scrolling down some list sometimes. The behavior is not obvious to me.

[cyring]

No I don't get issues in a plain shell terminal.
I tried the getkey.c program, but scrolling does not register as an input and just scrolls the terminal window as normal.
I tried xev which does register events from the scroll wheel but I don't know if any of the output are ASCII codes.

You're right, pressing [Escape] enough times finally gets rid of the red Driver message.
I realized that mouse wheel scrolling does not always cause the error. At some times it is taken as user input, for example opening a menu or scrolling down some list sometimes. The behavior is not obvious to me.

May be try catching mouse codes with:

./getkey -x

However, I'm far to be ready to support the Mouse in the CoreFreq UI.
This is reserved for CoreFreq.gui

[adatum]

The output is not consistent and changes each time.
The first time scroll down got: Poll(1)[262e614d5b1b] and scroll up got: Poll(1)[2370604d5b1b] but the part before 4d5b1b changes each time.
Also, after quitting getkey with Ctrl-C, moving the scroll wheel enters gibberish into the terminal, and the terminal text color is changed. I have to reset to return to normal behavior.

I don't expect mouse support for CoreFreq. I was just surprised by the unexpected behavior from an accidental mouse scrolling action.

[cyring]

The output is not consistent and changes each time.
The first time scroll down got: Poll(1)[262e614d5b1b] and scroll up got: Poll(1)[2370604d5b1b] but the part before 4d5b1b changes each time.
Also, after quitting getkey with Ctrl-C, moving the scroll wheel enters gibberish into the terminal, and the terminal text color is changed. I have to reset to return to normal behavior.

I don't expect mouse support for CoreFreq. I was just surprised by the unexpected behavior from an accidental mouse scrolling action.

Thanks.
The codes you dump are fixed Id of mouse event completed with motion, coordinates, or relative values like up, down increments.

It's still a draft code which supports X mouse, thus terminal is badly restored.

In the UI to-do list: I'll try to catch and discard the mouse events using masks of the fixed ASCII part.

[cyring]

Could you please test the latest develop commit and toggle several times C2U and C3U

This commit contains asm codes to atomically access the FCH.
In concurrent access case, CPU will retry 10 times, spaced by 5 ms

It works with my 3950X but be prepared for any lock, thus save your files.

[adatum]

All 4 combinations of C2U and C3U OFF/ON were tried with no ill effects noticed.

[cyring]

All 4 combinations of C2U and C3U OFF/ON were tried with no ill effects noticed.

Yes, Yes, Yes !
Thank you.