Bug 450190 - acpi-cpufreq detects incorrect maximum frequency on Intel T8100 processor
acpi-cpufreq detects incorrect maximum frequency on Intel T8100 processor
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-05 15:24 EDT by James
Modified: 2008-06-17 05:06 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-17 05:06:43 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)
dmesg output from affected kernel. (33.36 KB, text/plain)
2008-06-05 15:24 EDT, James
no flags Details
dmesg output booting cpufreq.debug=7 (65.55 KB, text/plain)
2008-06-05 15:46 EDT, James
no flags Details

  None (edit)
Description James 2008-06-05 15:24:56 EDT
Description of problem:
The maximum frequency is not detected correctly by acpi-cpufreq. The T8100
processor has a maximum clock of 2.1 GHz, but it's currently capped at 1.2 GHz:

$ cat /sys/devices/system/cpu/cpu?/cpufreq/scaling_max_freq
1200000
1200000

Version-Release number of selected component (if applicable):
kernel-2.6.25.4-16.fc8

How reproducible:
Always.

Actual results:
Only frequencies available are 800 MHz and 1.2 GHz.

Expected results:
Frequencies of 800 MHz, 1.2 GHz, 1.6 GHz and 2.1 GHz available.

Additional info:
kernel-2.6.24.7-92.fc8 had all frequencies available.

It's odd, this update seems to correct a few things on this notebook (events are
generated for lid, sleep button, etc.) but a few glitches remain.
dmesg attached.
See also: Bug 448150, Bug 448151 (probably the same issue). These pertain to the
same notebook.
Comment 1 James 2008-06-05 15:24:56 EDT
Created attachment 308478 [details]
dmesg output from affected kernel.
Comment 2 Dave Jones 2008-06-05 15:34:13 EDT
We've seen a few cases of this happening.  Can you post the dmesg output if you
boot with cpufreq.debug=7 please ?
Comment 3 James 2008-06-05 15:46:58 EDT
Created attachment 308480 [details]
dmesg output booting cpufreq.debug=7

For some reason gnome-power-manager is detecting two batteries... probably
unrelated to this, though.
Comment 4 James 2008-06-06 06:43:33 EDT
[Comment added to toggle NEEDINFO state.]
Comment 5 James 2008-06-12 06:55:35 EDT
Still present in kernel-2.6.25.6-24.fc8.
Comment 6 James 2008-06-12 06:58:49 EDT
OK, I've just noticed something... the previous test I did was on battery power.
Now when I plug in and do 

$ cat /sys/devices/system/cpu/cpu?/cpufreq/scaling_max_freq
2101000
2101000

This is not the behaviour I'm used to from the previous kernels which scaled to
the max on battery power. Also, the "power save" button on my notebook works as
well now, clocking down when activated. So, to be honest, I'm not sure if this
is a bona fide bug, or the kernel actually processing the notebooks ACPI BIOS as
intended.

Comment 7 James 2008-06-17 05:06:43 EDT
I'm going to close this NOTABUG for the time being, I believe the *frequency*
scaling is behaving as intended.

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