https://bugzilla.kernel.org/show_bug.cgi?id=198779

            Bug ID: 198779
           Summary: ASRock J3455M (Goldmont) does not reach PC10
           Product: ACPI
           Version: 2.5
    Kernel Version: 4.15.0
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Power-Processor
          Assignee: acpi_power-proces...@kernel-bugs.osdl.org
          Reporter: matts...@gmail.com
                CC: l...@kernel.org
        Regression: No

Created attachment 274151
  --> https://bugzilla.kernel.org/attachment.cgi?id=274151&action=edit
turbostat log

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?

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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla

Reply via email to