Bug 678700

Summary: CPU scaling reports incorrect maximum frequency
Product: [Fedora] Fedora Reporter: Pat Gardner <pat>
Component: kernelAssignee: John Feeney <jfeeney>
Status: CLOSED CANTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 14CC: gansalmon, itamar, jfeeney, jonathan, kernel-maint, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-08-30 18:01:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Output of acpidump > acpi.dat
none
Output of dmesg > dmesg.txt
none
SSDT[1-5] in zip file from /sys/firmware/acpi/tables none

Description Pat Gardner 2011-02-18 22:01:00 UTC
Description of problem:

The maximum frequency of the CPU (Q8400) should be 2.66GHz but is reported as 2.13GHz with a minimum of 1.6GHz.

Version-Release number of selected component (if applicable):

2.6.34.7-66.fc13.i686.PAE

How reproducible:

Always

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

# cpufreq-info 
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq.org, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 10.0 us.
  hardware limits: 1.60 GHz - 2.13 GHz
  available frequency steps: 2.13 GHz, 1.60 GHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 1.60 GHz and 2.13 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.60 GHz (asserted by call to hardware).
  cpufreq stats: 2.13 GHz:18.04%, 1.60 GHz:81.96%  (5616)
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 10.0 us.
  hardware limits: 1.60 GHz - 2.13 GHz
  available frequency steps: 2.13 GHz, 1.60 GHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 1.60 GHz and 2.13 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.60 GHz (asserted by call to hardware).
  cpufreq stats: 2.13 GHz:18.04%, 1.60 GHz:81.96%  (5616)
analyzing CPU 2:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 10.0 us.
  hardware limits: 1.60 GHz - 2.13 GHz
  available frequency steps: 2.13 GHz, 1.60 GHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 1.60 GHz and 2.13 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.60 GHz (asserted by call to hardware).
  cpufreq stats: 2.13 GHz:18.04%, 1.60 GHz:81.96%  (5616)
analyzing CPU 3:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 10.0 us.
  hardware limits: 1.60 GHz - 2.13 GHz
  available frequency steps: 2.13 GHz, 1.60 GHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 1.60 GHz and 2.13 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.60 GHz (asserted by call to hardware).
  cpufreq stats: 2.13 GHz:18.04%, 1.60 GHz:81.96%  (5616)

cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
2133000

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
2133000

The same values are reported for CPU's 0,1,2,3.

Comment 1 Pat Gardner 2011-02-19 09:08:21 UTC
The CPU is correctly identified:

# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Quad CPU    Q8400  @ 2.66GHz
stepping	: 10
cpu MHz		: 1600.000
cache size	: 2048 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips	: 5332.85
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

Comment 2 Bug Zapper 2011-05-30 11:18:45 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 3 Pat Gardner 2011-06-21 22:26:00 UTC
Also affects F14 with 2.6.35.13-92.fc14.i686.PAE

Comment 4 Matthew Garrett 2011-08-29 18:18:46 UTC
What system is this chip installed in? I suspect that your system firmware is unable to handle it correctly and is passing us incorrect values.

Comment 5 Pat Gardner 2011-08-29 20:07:18 UTC
The system is a Shuttle SX48P2 E

http://uk.shuttle.com/products/productsSpec?productId=1095

The latest BIOS '06' is installed.

I can provide information from acpidump if that will help.

Comment 6 Matthew Garrett 2011-08-29 21:16:24 UTC
Yes, acpidump would be helpful, as would dmesg. Thanks!

Comment 7 Pat Gardner 2011-08-29 21:56:55 UTC
Created attachment 520472 [details]
Output of acpidump > acpi.dat

Output of acpidump > acpi.dat

Comment 8 Matthew Garrett 2011-08-30 15:02:00 UTC
Ok, the relevant data seems to be loaded dynamically. Can you attach each of the files in /sys/firmware/acpi/tables/dynamic/ ?

Comment 9 Pat Gardner 2011-08-30 15:04:58 UTC
Created attachment 520622 [details]
Output of dmesg > dmesg.txt

Comment 10 Pat Gardner 2011-08-30 15:08:50 UTC
/sys/firmware/acpi/tables/dynamic/ is an empty directory.

Comment 11 Matthew Garrett 2011-08-30 15:16:01 UTC
Hm. Odd. Ok, can you attach anything in /sys/firmware/acpi/tables that starts SSDT?

Comment 12 Pat Gardner 2011-08-30 17:01:42 UTC
There is SSDT[1-5] but all 5 are empty files of zero size.

Comment 13 Matthew Garrett 2011-08-30 17:15:33 UTC
You may need to copy them out of /sys/firmware/acpi/tables before they appear correctly.

Comment 14 Pat Gardner 2011-08-30 17:51:14 UTC
Created attachment 520661 [details]
SSDT[1-5] in zip file from /sys/firmware/acpi/tables

Comment 15 Matthew Garrett 2011-08-30 18:01:02 UTC
        Name (SPSS, Package (0x02)
        {
            Package (0x06)
            {
                0x00000855, 

0x855 is decimal 2133, so your system firmware is reporting the incorrect frequency. I'm afraid we can't fix this in-kernel.