Bug 205611 - Upgrading to kernel-2.6.17-1.2174_FC5 loses CPU frequency scaling
Summary: Upgrading to kernel-2.6.17-1.2174_FC5 loses CPU frequency scaling
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 5
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2006-09-07 16:45 UTC by Bret Mogilefsky
Modified: 2015-01-04 22:28 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2006-10-20 19:37:22 UTC

Attachments (Terms of Use)

Description Bret Mogilefsky 2006-09-07 16:45:14 UTC
Description of problem:
Upgrading to the latest released FC5 kernel breaks CPU frequency scaling on my
notbook, which works fine with the previous kernel.

Version-Release number of selected component (if applicable):

How reproducible:
Every time.

Steps to Reproduce:
1. Running kernel 2.6.17-1.2157_FC5, note that CPU frequency scaling is alive
and well:
[root@madmax ~]# ls /sys/devices/system/cpu/cpu0/cpufreq
affected_cpus     ondemand                       scaling_driver
cpuinfo_cur_freq  scaling_available_frequencies  scaling_governor
cpuinfo_max_freq  scaling_available_governors    scaling_max_freq
cpuinfo_min_freq  scaling_cur_freq               scaling_min_freq

2. Reboot with kernel 2.6.17-1.2174_FC5
3. Note that CPU frequency scaling is dead and gone:
[root@madmax ~]# ls -l /sys/devices/system/cpu/cpu0/cpufreq
ls: /sys/devices/system/cpu/cpu0/cpufreq: No such file or directory
Actual results:
No CPU frequency scaling available.

Expected results:
CPU frequency scaling available.

Additional info:
[root@madmax ~]# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 9
model name      : Intel(R) Pentium(R) M processor 1400MHz
stepping        : 5
cpu MHz         : 600.000
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 mtrr pge mca cmov pat clflush
dts acpi mmx fxsr sse sse2 tm pbe est tm2
bogomips        : 1197.27

In my /etc/rc.local, I usually configure frequency scaling like so:
/sbin/modprobe cpufreq_ondemand
echo "ondemand" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Comment 1 Dave Jones 2006-10-16 20:47:00 UTC
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

Comment 2 Bret Mogilefsky 2006-10-17 16:31:55 UTC
In the time since my initial report, I tried it again when
kernel-2.6.17-1.2187_FC5 became available.   It seemed to work fine on that one.

I've just upgraded to kernel-2.6.18-1.2200.fc5 and tested again.  Frequency
scaling *is* available with this kernel.  However, when on battery power, the
scaling_max_freq is set to the lowest of the available set of frequencies.  This
behavior differs from previous versions of the kernel and to my understanding is
not how the ondemand governor is supposed to work.  However, this may be a
separate issue... If you want to mark this issue resolved, I can file a new
issue describing that as a separate problem.


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