Bug 746372
Summary: | Build cpufreq drivers as modules | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | nucleo <alekcejk> |
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 19 | CC: | dr.diesel, gansalmon, itamar, jforbes, jonathan, kernel-maint, madhu.chinakonda |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-04-05 16:24:15 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
nucleo
2011-10-15 02:41:35 UTC
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. 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. [mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update. [mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update. [mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update. Problem still in kernel-3.3.0-1.fc17.i686 Updated to include 17 and up to and including Kernel 3.6.0-rc1 as this problem still exists. Added mainline Kernel bug tracker. 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. 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. 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? 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. 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 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 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 This has now been changed for F19 and will make the next update. 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 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. |