Red Hat Bugzilla – Bug 84432
RFE: speedstep doesn't update /proc/cpuinfo
Last modified: 2007-04-18 12:51:18 EDT
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 speedstep_coppermine=1 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: Always 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
From what I can tell, speedstep does work, but /proc/cpuinfo just keeps displaying the on-boot status.
I still think it doesn't really work, judging from the following: [0] [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?
I _know_ it does work for me, but I adjust the values _manually_: /etc/sysconfig/apm-scripts/apmcontinue: #!/bin/sh case "$1" in change) case "$2" in power) if apm |grep -q on-line; then /usr/local/sbin/cpu-max else /usr/local/sbin/cpu-med fi ;; battery) /usr/local/sbin/cpu-min ;; esac ;; resume) if apm |grep -q on-line; then /usr/local/sbin/cpu-max else /usr/local/sbin/cpu-med fi ;; esac /usr/local/sbin/cpu-min: #!/bin/sh echo '0%1%75%powersave' > /proc/cpufreq cat /usr/local/sbin/cpu-med: #!/bin/sh echo '0%1%100%powersave' > /proc/cpufreq /usr/local/sbin/cpu-max: #!/bin/sh 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.
This problem still exists with kernel-2.4.20-20.1.1995.2.2.nptl in Rawhide.
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