Bug 84432 - RFE: speedstep doesn't update /proc/cpuinfo
Summary: RFE: speedstep doesn't update /proc/cpuinfo
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 9
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-02-16 21:54 UTC by Alex Papadopoulos
Modified: 2007-04-18 16:51 UTC (History)
2 users (show)

Fixed In Version: 2.6.5-1.351
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2004-05-12 05:45:39 UTC

Attachments (Terms of Use)

Description Alex Papadopoulos 2003-02-16 21:54:57 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130

Description of problem:
IBM Thinkpad T23:

[root@helios root]# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 11
model name      : Intel(R) Pentium(R) III Mobile CPU      1000MHz
stepping        : 1
cpu MHz         : 999.163
cache size      : 32 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 pae mce cx8 sep mtrr pge mca cmov pat
pse36 mmx fxsr sse
bogomips        : 1989.22

When I unplug the AC and work on battery, the speedstep module is not
automatically loaded. If I load it manually, it doesn't slow down the CPU (cpu
MHz remain constant). 

The only way of getting the CPU to slow down is booting while on battery. Then,
the speedstep module is loaded automatically and cpu MHz falls to 733, as it should.

To get the CPU back at full speed, plugging in AC is not enough, one has to
reboot while plugged in.

I tried the "speedstep_coppermine=1" parameter to speedstep, as suggested @ bug
77332, but got:

[root@helios root]# modprobe -v speedstep speedstep_coppermine=1
/sbin/insmod /lib/modules/2.4.18-24.8.0/kernel/arch/i386/kernel/speedstep.o
Using /lib/modules/2.4.18-24.8.0/kernel/arch/i386/kernel/speedstep.o
Symbol version prefix ''
Warning: ignoring speedstep_coppermine=1, no such parameter in this module
Module speedstep loaded, with warnings

In case it helps:
[root@helios root]# uname -a
Linux helios.localdomain 2.4.18-24.8.0 #1 Fri Jan 31 06:51:30 EST 2003 i686 i686
i386 GNU/Linux

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

How reproducible:

Steps to Reproduce:
1. Unplug laptop from AC
2. cat /proc/cpuinfo | grep MHz
3. Reboot
4. cat /proc/cpuinfo | grep MHz
5. Plug laptop back to AC
6. cat /proc/cpuinfo | grep MHz
7. Reboot
8. cat /proc/cpuinfo | grep MHz

Actual Results:  Without rebooting, the CPU frequency did not change.

Expected Results:  CPU frequency should dynamically change depending on power
source (AC vs battery)

Additional info:

apmd works fine - the kernel knows when power is connected and when we're on
battery. This is a snippet from /var/log/messages, when I unplug AC, load the
speedstep module, and then plug into AC again.

Feb 16 16:21:48 helios apmd[1362]: Now using Battery Power
Feb 16 16:22:15 helios kernel: cpufreq: Intel(R) SpeedStep(TM) support
$Revision: 1.34 $
Feb 16 16:22:15 helios kernel: cpufreq: change to 0 MHz succeded
Feb 16 16:22:15 helios kernel: cpufreq: change to 997 MHz succeded
Feb 16 16:22:15 helios kernel: cpufreq: currently at high speed setting - 997 MHz
Feb 16 16:22:15 helios kernel: CPU clock: 997.500 MHz (731.500-997.500 MHz)
Feb 16 16:22:47 helios apmd[1362]: Now using AC Power

Comment 1 Aleksey Nogin 2003-04-09 02:13:47 UTC
From what I can tell, speedstep does work, but /proc/cpuinfo just keeps
displaying the on-boot status.

Comment 2 Alex Papadopoulos 2003-04-09 19:16:38 UTC
I still think it doesn't really work, judging from the following:

[root@helios root]# w | grep average && grep MHz /proc/cpuinfo | grep cpu && apm
  2:09pm  up 15:25,  6 users,  load average: 0.03, 0.05, 0.07
cpu MHz         : 999.163
AC off-line, battery status high: 98% (1:31)
[root@helios root]# w | grep average && grep MHz /proc/cpuinfo | grep cpu && apm
  3:13pm  up 16:29,  6 users,  load average: 0.27, 0.25, 0.11
cpu MHz         : 999.163
AC off-line, battery status high: 31% (0:29)

This seems to suggest ~90mins of battery life, when under Windows it lasts ~150mins.

[1] [root@helios root]# lsmod | grep speed
speedstep               5820   0  (unused)

Is there some other way I can test whether it works or not?

Comment 3 Aleksey Nogin 2003-04-09 19:34:31 UTC
I _know_ it does work for me, but I adjust the values _manually_:


case "$1" in
      case "$2" in
         if apm |grep -q on-line; then
      if apm |grep -q on-line; then

echo '0%1%75%powersave' > /proc/cpufreq

cat /usr/local/sbin/cpu-med:
echo '0%1%100%powersave' > /proc/cpufreq

echo '0%75%100%performance' > /proc/cpufreq

I know it does work because the CPU becomes noticibly slower. I also know that
the /proc/cpuinfo is never updated. It's quite possible that there are several
bugs here _in addition_ to "/proc/cpuinfo never updated". It's possible that
speedstep does not work by default, does not work on certain hardware, etc. You
might want to file separate bugs on those issues (especially if you have better
evidence than "battery does not last as long" - that does not necessarily mean
speedstep is not working, it may very well be other factors, such as HDD never
powering down). But the "speedstep doesn't update /proc/cpuinfo" issue is
definitely a bug and fixing that would make debugging others _much_ easier.

Comment 4 Aleksey Nogin 2003-05-30 21:55:04 UTC
This problem still exists with kernel-2.4.20-20.1.1995.2.2.nptl in Rawhide.

Comment 5 Aleksey Nogin 2004-05-12 05:45:39 UTC
This seems to work correctly in Raw Hide (and FC2, I am guessing):

# echo 1800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
# grep MHz /proc/cpuinfo
cpu MHz         : 1795.286
# echo 1200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
# grep MHz /proc/cpuinfo
cpu MHz         : 1196.857

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