Bug 746372 - Build cpufreq drivers as modules
Build cpufreq drivers as modules
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-14 22:41 EDT by nucleo
Modified: 2013-04-19 01:46 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-05 12:24:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 46211 None None None 2012-08-19 08:58:10 EDT

  None (edit)
Description nucleo 2011-10-14 22:41:35 EDT
Description of problem:
I have Intel Core2 Duo E6300 processor slightly overclocked with 2145 MHz but there is wrong frequency in /proc/cpuinfo: "cpu MHz : 1596.000"

Version-Release number of selected component (if applicable):
kernel-3.1.0-0.rc9.git0.0.fc16.i686

Actual results:
processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz
stepping        : 6
cpu MHz         : 1596.000
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic 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 lahf_lm dts tpr_shadow
bogomips        : 4289.88
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:


Expected results:
processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz
stepping        : 6
cpu MHz         : 2145.378
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic 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 lahf_lm dts tpr_shadow
bogomips        : 4290.55
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:


Additional info:
I also tried kernels:

kernel-3.0-0.rc6.git6.1.fc16.i686 which also shows "cpu MHz : 1596.000"

and 

kernel-3.0-0.rc6.git0.1.fc16.i686 which shows "cpu MHz : 2145.378" as it should be.

So I suppose that this bug is related with changes in kernel-3.0-0.rc6.git6.1.fc16.i686:

* Thu Jul 07 2011 Dave Jones <davej@redhat.com>
- Centralise CPU_FREQ options into config-generic. 
  Switch to using ondemand by default. (rhbz 713572)

I installed kernel-tools package where is cpupower.service provided in bug 713572 (this package is not installed by default) and started cpupower.service. 

But after cpupower.service started there is "cpu MHz : 1862.000" in /proc/cpuinfo which is also not actual CPU frequency 2145 MHz.
Comment 1 nucleo 2011-10-18 15:07:30 EDT
This is source of problems with time in virtual machine that became too much
different from time in host system. Both ntpd and chrony can't synchronize time in VM's because of large offset.

# cpupower frequency-info
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 1.60 GHz - 1.86 GHz
  available frequency steps: 1.86 GHz, 1.60 GHz
  available cpufreq governors: conservative, userspace, powersave, ondemand,
performance
  current policy: frequency should be within 1.60 GHz and 1.86 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).
  boost state support:
    Supported: yes
    Active: yes

So it is not able to set frequency to 2145 MHz (which I set in BIOS) because
maximum here is 1.86 GHz. But real frequency shown by "cpupower monitor" is near 2145 MHz.

Frequency which I set in BIOS is not in range detected by cpufreq drivers and cpupower. The obly way to get right frequency in /proc/cpuinfo is remove cpufreq modules.
Comment 2 nucleo 2011-10-18 15:08:55 EDT
I disabled SpeedStep in BIOS.
acpi-cpufreq built-in module was loaded when SpeedStep was enabled.
I expected that cpufreq will be completely disabled in kernel after disabling
SpeedStep but p4-clockmod built-in cpufreq module used instead of acpi-cpufreq
and CPU frequency again changed to 1.87 GHz.

Here some kernel messages:

Detected 2145.326 MHz processor.
Calibrating delay loop (skipped), value calculated using timer frequency..
4290.65 BogoMIPS (lpj=2145326)
.................
p4-clockmod: Warning: EST-capable CPU detected. The acpi-cpufreq module offers
voltage scaling in addition to frequency scaling. You should use that instead 
of p4-clockmod, if possible.
ondemand governor failed, too long transition latency of HW, fallback to
performance governor
ondemand governor failed, too long transition latency of HW, fallback to
performance governor
p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available

And what is in /proc/cpuinfo now:

cpu MHz         : 1866.669
bogomips        : 4290.55

/sys/devices/system/cpu/cpufreq is empty now.

So your assumption that kernel itself can decide which driver to use is
incorrect because kernel should not load any frequency scaling module after
scaling was disabled in BIOS but it still loads cpufreq module.

I also disabled in BIOS other power saving options "Enabled C1 control" and
"CPU Internal Thermal Control" but even after this p4-clockmod built-in module
was used by kernel.
This is completely wrong kernel behavior.
Comment 3 Dave Jones 2012-03-22 12:59:09 EDT
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 4 Dave Jones 2012-03-22 13:03:12 EDT
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 5 Dave Jones 2012-03-22 13:14:08 EDT
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 6 nucleo 2012-03-23 17:56:09 EDT
Problem still in kernel-3.3.0-1.fc17.i686
Comment 7 Andy Lawrence 2012-08-19 08:37:02 EDT
Updated to include 17 and up to and including Kernel 3.6.0-rc1 as this problem still exists.
Comment 8 Andy Lawrence 2012-08-19 08:58:10 EDT
Added mainline Kernel bug tracker.
Comment 9 Andy Lawrence 2012-08-23 06:05:17 EDT
Well, the Kernel guys say this is not a bug, but a feature request, and closed my kernel bug report....

/proc/cpuinfo is not much use to newer Intel processors with Turbo mode, or any K series that is underclocked/overclocked.

Do 'yum install kernel-tools' and use the 'turbostat -v' command to find the correct clock frequency.

Leaving this bug open as it is still reported incorrectly.
Comment 10 nucleo 2012-08-23 06:10:26 EDT
Building CPUFREQ drivers as modules again instead of bilt-in can fix problem because if drivers not loaded no such problem.
This should be done in 3.4 kernel when CPU modailases was implemented (see bug 713572) but drivers are still built in kernel.
Comment 11 nucleo 2013-03-01 17:21:54 EST
CPU modaliases that should make possible auto-load cpufreq drivers was implemented in 3.4 but kernel 3.8 still have those drivers built-in.
Is there still problems with building cpufreq drivers as modules?
Comment 12 nucleo 2013-03-06 16:42:17 EST
I tested cpufreq modules autoloading on E6300 CPU with 3.7.10 kernel rebuilt with cpufreq drivers as modules.

First I set in BIOS "Intel Speed Step" to Auto and booted with this kernel and  found that acpi_cpufreq module was loaded.

Then I set in BIOS "Intel Speed Step" to disabled and found that no one of cpufreq drivers was loaded. 
This is expected behavior, cpufreq modules autoloading works as expected.
So it should be possible to make this drivers as modules again.
Comment 13 Dave Jones 2013-03-14 14:02:34 EDT
changed in rawhide.

The one exception is the new intel_pstate driver, which can't be made modular right now.  Hopefully there's no ordering interaction between that being loaded and the others not being built-in.

if this works out, we'll backport it to 19
Comment 14 nucleo 2013-03-18 11:13:29 EDT
I tested kernel-3.9.0-0.rc3.git0.3.fc20.i686.rpm on E63oo with the same results as in Comment 12.
Also I tested it on eeepc x101ch. acpi_cpufreq driver was loaded, 'cpupower frequency-info' shows:

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: 600 MHz - 1.60 GHz
  available frequency steps: 1.60 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz, 600 MHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance
  current policy: frequency should be within 600 MHz and 1.60 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 600 MHz.
  boost state support:
    Supported: no
    Active: no
Comment 15 Fedora End Of Life 2013-04-03 16:26:37 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 16 Justin M. Forbes 2013-04-05 12:24:15 EDT
This has now been changed for F19 and will make the next update.
Comment 17 Fedora Update System 2013-04-09 01:13:36 EDT
kernel-3.9.0-0.rc6.git0.1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/kernel-3.9.0-0.rc6.git0.1.fc19
Comment 18 Fedora Update System 2013-04-19 01:46:57 EDT
kernel-3.9.0-0.rc6.git2.3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.