ASRock J3455M (Goldmont) does not reach cstatePC10

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   I built a low power Linux machine with a J3455M. I noticed, when running powertop (https://en.wikipedia.org/wiki/PowerTOP) that the lowest package cstate I could reach was PC6, while PC10 should be reachable. powertop shows the CPUs in C10, core in C6, and package in C6. No residency in PC10. turbostat agrees.

From the Intel Software Developers' Manual, Vol. 4 [1], I know that there are MSRs for core C1/C3/C6 and package C2/C3/C6/C10. Also confirmed by the commit message of 5c10b048c37c ("perf/x86/intel: Enable C-state residency events for Apollo Lake")

In the attached turbostat log, I noticed something odd:

cpu1: MSR_PKG_CST_CONFIG_CONTROL: 0x14008072 (... pkg-cstate-limit=2 ...)

The BIOS allows you to limit the deepest cstate, with options disabled, C1, C6, C7, C8, C9, C10. I tried each option and did a "rdmsr 0xe2" with each set:

BIOS limit    powertop reports     rdmsr 0xe2
  disabled    no pkg residency           8000
        C1                 PC2       14008012
        C6                 PC6       14008032
        C7                 PC6       14008042
        C8                 PC6       14008052
        C9                 PC6       14008062
       C10                 PC6       14008072

According to ISD Vol 4 [1] Table 2-12, bits 3:0 of Goldmont's MSR_PKG_CST_CONFIG_CONTROL are:

0000b: No limit
0001b: C1
0010b: C3
0011b: C6
0100b: C7
0101b: C7S
0110b: C8
0111b: C9
1000b: C10

Until C7S, these correspond to bits 7:4 of my readings of 0xe2 (with a missing C3 fitting in as 14008022). The high bits are the lock bit (bit 15) and presumably demote/undemote bits, though those are not documented for Goldmont.

Is the BIOS programming the wrong nibble? 0x2 in the low nibble looks like it would be C3 and maybe the undemotion bit would cause the package to use C6?

Maybe I'm off on a tangent?

I'm hoping ASRock will see this message and determine that this is indeed a BIOS bug that they will fix.

[1] https://software.intel.com/sites/default/files/managed/22/0d/335592-sdm-vol-4.pdf

Edited by mattst88 - 21 Feb 2018 at 1:02am

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
mattst88 Members Profile Send Private Message Find Members Posts Add to Buddy List Newbie Joined: 21 Feb 2018 Status: Offline Points: 3	Post Options Post Reply Quote mattst88 Report Post Thanks(0) Quote Reply Topic: ASRock J3455M (Goldmont) does not reach cstatePC10 Posted: 21 Feb 2018 at 12:50am
	I built a low power Linux machine with a J3455M. I noticed, when running powertop (https://en.wikipedia.org/wiki/PowerTOP) that the lowest package cstate I could reach was PC6, while PC10 should be reachable. powertop shows the CPUs in C10, core in C6, and package in C6. No residency in PC10. turbostat agrees. From the Intel Software Developers' Manual, Vol. 4 [1], I know that there are MSRs for core C1/C3/C6 and package C2/C3/C6/C10. Also confirmed by the commit message of 5c10b048c37c ("perf/x86/intel: Enable C-state residency events for Apollo Lake") In the attached turbostat log, I noticed something odd: cpu1: MSR_PKG_CST_CONFIG_CONTROL: 0x14008072 (... pkg-cstate-limit=2 ...) The BIOS allows you to limit the deepest cstate, with options disabled, C1, C6, C7, C8, C9, C10. I tried each option and did a "rdmsr 0xe2" with each set: BIOS limit powertop reports rdmsr 0xe2 disabled no pkg residency 8000 C1 PC2 14008012 C6 PC6 14008032 C7 PC6 14008042 C8 PC6 14008052 C9 PC6 14008062 C10 PC6 14008072 According to ISD Vol 4 [1] Table 2-12, bits 3:0 of Goldmont's MSR_PKG_CST_CONFIG_CONTROL are: 0000b: No limit 0001b: C1 0010b: C3 0011b: C6 0100b: C7 0101b: C7S 0110b: C8 0111b: C9 1000b: C10 Until C7S, these correspond to bits 7:4 of my readings of 0xe2 (with a missing C3 fitting in as 14008022). The high bits are the lock bit (bit 15) and presumably demote/undemote bits, though those are not documented for Goldmont. Is the BIOS programming the wrong nibble? 0x2 in the low nibble looks like it would be C3 and maybe the undemotion bit would cause the package to use C6? Maybe I'm off on a tangent? I'm hoping ASRock will see this message and determine that this is indeed a BIOS bug that they will fix. [1] https://software.intel.com/sites/default/files/managed/22/0d/335592-sdm-vol-4.pdf Edited by mattst88 - 21 Feb 2018 at 1:02am