Bug 181045 - Frequency scaling not working with Pentium M and speedstep-centrino module
Frequency scaling not working with Pentium M and speedstep-centrino module
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-12 03:15 EST by Fabio Comolli
Modified: 2015-01-04 17:25 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-18 20:24:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of /proc/cpuinfo (430 bytes, text/plain)
2006-02-12 03:21 EST, Fabio Comolli
no flags Details
This patch found on the internet seems to fix it (3.70 KB, patch)
2006-02-12 03:28 EST, Fabio Comolli
no flags Details | Diff

  None (edit)
Description Fabio Comolli 2006-02-12 03:15:54 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060208 Fedora/1.5.0.1-2.1 Firefox/1.5.0.1

Description of problem:
My laptop has a Pentium M CPU @ 1.6 GHz.
CPU frequency scaling does not work as the directory /sys/devices/system/cpu/cpu0/cpufreq does not exist on the system.

This also happens with vanilla 2.6.16-rc2-git10.

Version-Release number of selected component (if applicable):
kernel-2.6.15-1.1928_FC5

How reproducible:
Always

Steps to Reproduce:
1. boot the kernel
2. ls /sys/devices/system/cpu/cpu0/
3.
  

Actual Results:  The directory cpufreq does not exist

Expected Results:  The directory cpufreq should exist

Additional info:
Comment 1 Fabio Comolli 2006-02-12 03:21:23 EST
Created attachment 124553 [details]
Output of /proc/cpuinfo
Comment 2 Fabio Comolli 2006-02-12 03:28:00 EST
Created attachment 124554 [details]
This patch found on the internet seems to fix it

I found this anonymous patch on the internet. Applied on the latest vanilla git
seems to fix the problem. Now the cpufreq directory exist. Output of ls -l
follows:

[fcomolli@kepler ~]$ ls -l /sys/devices/system/cpu/cpu0/cpufreq/
total 0
-r--r--r-- 1 root root 4096 Feb 12 09:05 affected_cpus
-r-------- 1 root root 4096 Feb 12 09:05 cpuinfo_cur_freq
-r--r--r-- 1 root root 4096 Feb 12 09:05 cpuinfo_max_freq
-r--r--r-- 1 root root 4096 Feb 12 09:05 cpuinfo_min_freq
-r--r--r-- 1 root root 4096 Feb 12 09:05 scaling_available_frequencies
-r--r--r-- 1 root root 4096 Feb 12 09:05 scaling_available_governors
-r--r--r-- 1 root root 4096 Feb 12 09:05 scaling_cur_freq
-r--r--r-- 1 root root 4096 Feb 12 09:05 scaling_driver
-rw-r--r-- 1 root root	  0 Feb 12 09:21 scaling_governor
-rw-r--r-- 1 root root 4096 Feb 12 09:05 scaling_max_freq
-rw-r--r-- 1 root root 4096 Feb 12 09:05 scaling_min_freq
-rw-r--r-- 1 root root	  0 Feb 12 09:24 scaling_setspeed
drwxr-xr-x 2 root root	  0 Feb 12 09:05 stats
[fcomolli@kepler ~]$
Comment 3 Fabio Comolli 2006-02-12 15:00:59 EST
Here is where I found the patch:

http://www.ussg.iu.edu/hypermail/linux/kernel/0408.0/1488.html
Comment 4 Dave Jones 2006-02-18 20:24:30 EST
dothan cpu is unsupportable.  The patch may work for you, but it definitly
doesn't work for others.  The problem is we've no way of knowing how the VID's
are wired up.

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