Bug 450190 - acpi-cpufreq detects incorrect maximum frequency on Intel T8100 processor
Summary: acpi-cpufreq detects incorrect maximum frequency on Intel T8100 processor
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 8
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-05 19:24 UTC by James
Modified: 2008-06-17 09:06 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-06-17 09:06:43 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
dmesg output from affected kernel. (33.36 KB, text/plain)
2008-06-05 19:24 UTC, James
no flags Details
dmesg output booting cpufreq.debug=7 (65.55 KB, text/plain)
2008-06-05 19:46 UTC, James
no flags Details

Description James 2008-06-05 19:24:56 UTC
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 19:24:56 UTC
Created attachment 308478 [details]
dmesg output from affected kernel.

Comment 2 Dave Jones 2008-06-05 19:34:13 UTC
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 19:46:58 UTC
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 10:43:33 UTC
[Comment added to toggle NEEDINFO state.]

Comment 5 James 2008-06-12 10:55:35 UTC
Still present in kernel-2.6.25.6-24.fc8.

Comment 6 James 2008-06-12 10:58:49 UTC
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 09:06:43 UTC
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.