I suspect this is a kernel bug (and will assign to Darren) On a 3.16 kernel (yocto built) it lacks the P-State driver and cpufreq min/max reports as follows: min: # cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq 432000 max: # cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq 1330000 If you were to load the P-state driver on an Arch 3.16 kernel (also reported for Ubuntu) you get min: # cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq 400000 max: # cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq 1000000 Indicating that the p-state driver is throttling the cpu well below it's max frequency. Is this just a miss-understanding of what p-state is doing, or an indication of something else?
Re-assigning to dvhart
NEEDINFO just want Darren to triage this if it's a kernel bug or a firmware bug, as it's not clear which is at fault
If you are not using intel_pstate the system is likely using acpi_cpufreq as the scaling driver and the values are being read for a table supplied by the BIOS. intel_pstate enumerates the available P states by reading the MSRs on the CPU. You can tell what scaling driver and governor is in use with: grep . /sys/devices/system/cpu/cpu0/cpufreq/* To get the values the CPU is reporting take returned values time 100Mhz for frequency. Min freq: rdmsr -d -f 16:8 0x66a Max Freq/stamped freq: rdmsr -d -f 24:16 0x66a Max turbo: rdmsr -d -f 8:0 0x66c I looks like the BIOS is reporting something different from what the CPU is.
After a little more investigation I think the issue is with acpi_cpufreq. acpi_cpufreq does not know anything about BYT on BYT the bottom 8 bits of MSR_IA32_PERF_CTL are used to set the VID (voltage) This method predates acpi_cpufreq for some reason BYT went back to having the OS set the VID. The value passed up in the BIOS table includes the VID for the associated frequency as a bit pattern that gets written to MSR_IA32_PERF_CTL. When filling in the frequency tables and reading the MSR_IA32_PERF_CTL acpi_cpufreq does not mask off the lower 8 bits. This is where the strange frequency numbers are coming from.
So my concern there is that the strange frequencies are happening with the p-state driver, not the acpi_cpufreq driver, since it's with the p-state driver that the supposed max cpu frequency is 1ghz vs. 1.33ghz
The strange frequencies are coming from apci_cpufreq not intel_pstate. The table entries returned by the BIOS contain the VID (voltage ID) for the frequency in the lower 8 bits the P state/frequency are in bits 15:8. When reporting the frequencies acpi_cpufreq blindly multiplies the value and returns it as the frequency. Prior to BYT the lower 8 bits were always zero. If you use rdmsr as described below you will see what the CPU is reporting.
Created attachment 2159 [details] Fix frequency reporting for BYT
I retract my previous comment on the BIOS misreporting frequency. BYT has a different method of mapping P state to frequency from the core processors. The attached patch fixes the issue on my BYT based system.
With the patch from Dirk applied to 3.17-rc7 with both drivers compiled in (=y): CONFIG_X86_ACPI_CPUFREQ=y CONFIG_X86_INTEL_PSTATE=y $ cat /sys/devices/system/cpu/cpu0/driver/cpu0/cpufreq/scaling_driver intel_pstate I see the following: $ cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq 533200 $ cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq 1333000 The max looks correct, but the min is different from both the originally reported values. 533MHz is the base frequency for the Graphics on this part, so it isn't surprising, but does this mean ACPI is providing the wrong data too?
You can check my math but section 13.6.2 of the BWG says the frequency is target ratio * bus frequency. In this case 4 * 133.3 MHz = 533.2 MHz for min frequency. I just reread the section and I can't find any way to come up with the 432000 number.
Now that we have a kernel fix working it's way upstream, thanks Dirk!, I'm kicking this back over to Tim to verify the acpi frequency tables we're passing up from firmware as the min frequency appears to be incorrect as reported from there. Tim, can you investigate why the firmware tables are reporting 400MHz instead of 533MHz?
Darren, I got the email from John , seems that everything is working for this bug, so can we close this bug?
Created attachment 2176 [details] Mail from JOhn
Hi John, Could you help reivew it and then close it?
As a note this bug is staying open as a tracking bug till the patch makes it into a mainline kernel
merged commit b27580b05e6f5253228debc60b8ff4a786ff573a
Dirk has completed the fix, the driver is enabled in yocto builds, although it will not have the fix until the next stable update, which is a normal part of the release process. Marking as closed. Thank you Dirk!