-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[AMD][Family 17h] Globale C-States #195
Comments
CC6 activation fixed in commit 47b46d6 Vcore and Power consumed tests |
Thanks. 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. |
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. EDIT: I do also blacklist cpufreq drivers and |
As part of commit 8e4add9 , the BIOS Global C-State is reported through CoreFreq
|
PMx07E [CStateEn] (FCH::PM::CStateEn)
As part of commit f1c0e8e , the CoreFreq Experimental mode is required to read the Power Management (PM) Registers
|
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 ?
|
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. |
Yes, mouse scroll wheel, up and down. |
Do you get the same in a plain shell terminal or console ? EDIT: here's a program I did to dump keys
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 ! |
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) |
No I don't get issues in a plain shell terminal. You're right, pressing [Escape] enough times finally gets rid of the red Driver message. |
May be try catching mouse codes with:
However, I'm far to be ready to support the Mouse in the CoreFreq UI. |
The output is not consistent and changes each time. I don't expect mouse support for CoreFreq. I was just surprised by the unexpected behavior from an accidental mouse scrolling action. |
Thanks. 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. |
Could you please test the latest This commit contains asm codes to atomically access the FCH. It works with my 3950X but be prepared for any lock, thus save your files. |
All 4 combinations of |
Yes, Yes, Yes ! |
BIOS C-States option
MSR 0xc0010296
with a mask of0x0000000000404040
seems to be the C-States enablement modeThe text was updated successfully, but these errors were encountered: