Bug 587764 - CPU frequency isn't correctly detected by cpufreq-utils
CPU frequency isn't correctly detected by cpufreq-utils
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: cpufrequtils (Show other bugs)
13
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Anton Arapov
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-30 15:59 EDT by Doru Barbu
Modified: 2014-06-18 04:02 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-17 05:15:02 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)
dmidecode output (16.48 KB, text/plain)
2010-04-30 16:52 EDT, Doru Barbu
no flags Details
Contents of /proc/cpuinfo (546 bytes, text/plain)
2010-05-05 09:03 EDT, Doru Barbu
no flags Details
dmesg output from a fresh boot (37.18 KB, text/plain)
2010-05-05 09:06 EDT, Doru Barbu
no flags Details
/proc/acpi/dsdt (18.57 KB, application/octet-stream)
2010-05-10 14:34 EDT, Doru Barbu
no flags Details
/proc/acpi/dsdt file after bios flash & reset to optimized defaults (18.57 KB, application/octet-stream)
2010-05-18 03:54 EDT, Doru Barbu
no flags Details

  None (edit)
Description Doru Barbu 2010-04-30 15:59:22 EDT
Description of problem:
The kernel cpu frequency scaling module (p4_clockmod) and cpufreq-utils doesn't detect the correct range of frequencies supported by the processor.

In /proc/cpuinfo, the CPU is correctly detected:
"model name	: Intel(R) Pentium(R) M processor 2.00GHz"
However, cpufreq-info returns:
"  hardware limits: 75.0 MHz - 600 MHz
  available frequency steps: 75.0 MHz, 150 MHz, 225 MHz, 300 MHz, 375 MHz, 450 MHz, 525 MHz, 600 MHz"

These same frequency steps are available through GNOME CPU Frequency Monitor applet, and the frequency reported by /proc/cpuinfo changes reflecting the selection in the applet.

By removing the p4_clockmod module, the frequency reported by /proc/cpuinfo is 799.922MHz.

In Ubuntu 9.04 the processor's frequency is correctly detected and scaling occurs between 800MHz and 2GHz.

Version-Release number of selected component (if applicable):
cpufrequtils 007-1.fc13
kernel 2.6.33.2-57.fc13.i686.PAE

This problem occurs on an Fujitsu-Siemens Amilo M1437G laptop. If any other hardware or software-related details are necessary, I will provide them a.s.a.p.
Comment 1 Doru Barbu 2010-04-30 16:52:33 EDT
Created attachment 410597 [details]
dmidecode output
Comment 2 Anton Arapov 2010-05-05 07:17:47 EDT
Doru, please provide the contents of /proc/cpuinfo and a dmesg dump from a fresh boot with cpufreq.debug=7 added as a kernel boot parameter.
Comment 3 Doru Barbu 2010-05-05 09:03:51 EDT
Created attachment 411587 [details]
Contents of /proc/cpuinfo
Comment 4 Doru Barbu 2010-05-05 09:06:04 EDT
Created attachment 411591 [details]
dmesg output from a fresh boot

Interesting sequences in terms of cpu frequency scaling debug are at line 363, where speedstep takes a first look at the processor, and after line 730, when the p4_clockmod governor is chosen and the frequency ranges are established.
Comment 5 Anton Arapov 2010-05-10 06:45:32 EDT
Doru, could you check the following things:
1. your current BIOS version; Update it to the latest one;
   = check if it works;
   = there was known issue with Amilo hardware.
2. check if there are an option in the BIOS that forbids/allows frequency scaling;
   = must be enabled;
3. attach your /proc/acpi/dsdt to bugzilla;

p4_clockmod is the fallback driver, and works bad for your case. acpi_cpufreq must be working on your hardware.

and we already hit your problem in the past, you can read the bug comments here:
https://bugzilla.kernel.org/show_bug.cgi?id=8228, it might be helpful to you.

you can workaround the issue by preventing the p4_clockmod of loading.

Let me know the results. Cheers!
Comment 6 Doru Barbu 2010-05-10 14:34:44 EDT
Created attachment 412923 [details]
/proc/acpi/dsdt

I checked the bios version, and it's the latest as posted on the fujitsu support website (version 1.10C).
There are no cpu frequency related options in the bios, except maybe for a "Enable power saving mode" option which doesn't appear to change anything while running fedora.
IIRC, enabling this option while using Windows forced the cpu to the lowest possible frequency, but I don't remember for sure.

I checked out the messages on bug 8228, but I wasn't able to stop p4_clockmod from loading. I tried adding it to the /etc/modprobe.d/blacklist.conf file, but it is still loaded. Removing it at runtime works, but acpi_cpufreq still isn't loaded, instead it returns this:
FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.33.3-85.fc13.i686.PAE/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko): Device or resource busy

I will try to find other ways to stop modules from loading at boot, and eventually I will try to go over the custom patches that the ubuntu team adds to their kernel.

In the mean time, I attached the /proc/acpi/dsdt file, I hope it will shed some more light on why this is happening. Thanks!
Comment 7 Doru Barbu 2010-05-15 10:14:55 EDT
I went as far as actually moving p4_clockmod from /lib/modules, and acpi_cpufreq still doesn't load, but now I get a slightly different error:

FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.33.3-85.fc13.i686.PAE/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko): No such device

I guess p4_clockmod wasn't the culprit for acpi_cpufreq's failure to load after all. Any more ideas about what I should try?

Cheers!
Comment 8 Anton Arapov 2010-05-17 05:15:02 EDT
Doru, "modprobe acpi_cpufreq" fails because your dsdt has:
  OperationRegion (SSDT, SystemMemory, 0xFFFF0000, 0xFFFF)
  // you can see it by iasl -d %your_dsdt_file%
that means freq scaling disabled in the BIOS. Ubuntu has patched sources where they workaround this issue.
and as per comment:
  https://bugzilla.kernel.org/show_bug.cgi?id=8228&mark=46#c46
the issue was fixed by the BIOS from 2004.

  We are not going to do workaround bits in kernel, it's not the right way to solve the issue and thus have no chances to get into mainline kernel.

  I also believe Fujitsu won't be pay attention since the laptop is old and unsupported this days.

  I would recommend to re-open the bug 8228 at kernel.org's bugzilla and mention that you have exactly the same situation as Daniel Swarbrick had and BIOS updated didn't work it out for you.

  hence I'm closing the bug for now, as WONTFIX, it's BIOS issue.

Cheers!
Comment 9 Doru Barbu 2010-05-17 06:43:52 EDT
Thank you for the link to the kernel.org bug report. Following the original poster's idea, I reflashed bios 1.10C and then I resetted to optimal defaults.
Magically, it works. The weird part is that I can't see any bios options to be different than they way they were set up before.

I suspect that, when flashing a new bios, the old options are preserved and they somehow impair newly implemented features. I'm saying that because, after flashing, I didn't get any "CMOS checksum bad" kind of error.

Anyhow, thanks again!
Comment 10 Anton Arapov 2010-05-18 03:27:08 EDT
Doru, thanks for the feedback.

And please, attach your /proc/acpi/dsdt to this bug again. I'd like to look into, what has changed.

thanks,
Comment 11 Doru Barbu 2010-05-18 03:54:27 EDT
Created attachment 414764 [details]
/proc/acpi/dsdt file after bios flash & reset to optimized defaults

Apparently, there aren't many changes to speak of. OperationRegion did change, and the Method (USXD, [...]) statements became Method (_S3D, [...]).

I'll just paste below a diff between the iasl output for the old and new dsdt, and I will attach the new dsdt file.

===========================================

-DefinitionBlock ("dsdt.aml", "DSDT", 1, "UW____", "F19_____", 0x00000001)
+DefinitionBlock ("dsdt_after.aml", "DSDT", 1, "UW____", "F19_____", 0x00000001)
 {
     Scope (\_PR)
     {
         Processor (CPU1, 0x01, 0x00000810, 0x06)
         {
-            OperationRegion (SSDT, SystemMemory, 0xFFFF0000, 0xFFFF)
-            Name (NCPU, 0x00)
+            OperationRegion (SSDT, SystemMemory, 0x2FFD4EC0, 0x03F6)
+            Name (NCPU, 0x01)
             Name (TYPE, 0x80000000)
             Name (HNDL, 0x80000000)
             Method (_PDC, 1, NotSerialized)
@@ -890,7 +890,7 @@ DefinitionBlock ("dsdt.aml", "DSDT", 1, 
                 Return (PR00)
             }
 
-            Method (USXD, 0, NotSerialized)
+            Method (_S3D, 0, NotSerialized)
             {
                 If (LOr (LEqual (OSFL (), 0x01), LEqual (OSFL (), 0x02)))
                 {
@@ -2907,7 +2907,7 @@ DefinitionBlock ("dsdt.aml", "DSDT", 1, 
                             Offset (0x01)
                 }
 
-                Method (USXD, 0, NotSerialized)
+                Method (_S3D, 0, NotSerialized)
                 {
                     If (LOr (LEqual (OSFL (), 0x01), LEqual (OSFL (), 0x02)))
                     {
@@ -2942,7 +2942,7 @@ DefinitionBlock ("dsdt.aml", "DSDT", 1, 
                             Offset (0x01)
                 }
 
-                Method (USXD, 0, NotSerialized)
+                Method (_S3D, 0, NotSerialized)
                 {
                     If (LOr (LEqual (OSFL (), 0x01), LEqual (OSFL (), 0x02)))
                     {
@@ -2977,7 +2977,7 @@ DefinitionBlock ("dsdt.aml", "DSDT", 1, 
                             Offset (0x01)
                 }
 
-                Method (USXD, 0, NotSerialized)
+                Method (_S3D, 0, NotSerialized)
                 {
                     If (LOr (LEqual (OSFL (), 0x01), LEqual (OSFL (), 0x02)))
                     {
@@ -3012,7 +3012,7 @@ DefinitionBlock ("dsdt.aml", "DSDT", 1, 
                             Offset (0x01)
                 }
 
-                Method (USXD, 0, NotSerialized)
+                Method (_S3D, 0, NotSerialized)
                 {
                     If (LOr (LEqual (OSFL (), 0x01), LEqual (OSFL (), 0x02)))
                     {
Comment 12 Anton Arapov 2010-05-18 04:18:19 EDT
perfect, that's what I looked for. :) thanks!

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