Kernel Bug Tracker – Bug 6331
cpu frequency gets lowered by kernel when cord is pulled(init=bin/sh)
Last modified: 2006-04-13 12:16:20 UTC
Most recent kernel where this bug did not occur: unknown
Distribution: ubuntu dapper
Hardware Environment: Dell inspiron 9300 Inetl Pentium M 1.73 using
Software Environment: ubuntu dapper gcc 4.0.3
when ac cord is pulled (even in single user mode, or with init=/bin/sh)
get's set to the scaling_min_freq automatically
any scripts that run and try to set scaling_max_freq to something else end up
instead making sure that this gets reverted back to min freq
this is using the performance governor.
Steps to reproduce:
boot kernel with flag init=/bin/sh and ac plugged in (to make sure no other
scripts of anything could possibly be changing this)
# mount /sys
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
repeat last step until it eventually goes back to the full frequency and stays
a workaround for scrits that normally control these things is to have them sleep
for a while after an AC event has occured.
forgot to mention I have all of the following patches on this page
I've seen a bunch of machines do this, and there's not a thing we can do about
it. The kernel isn't what's changing the speed, the BIOS is doing it via SMM
traps when a power change occurs. It's taken quite a bit of work for the
kernel to event detect that this has happened, as SMMs are completely
transparent to the OS. (That's why it takes a while for the kernel to realise
that it changed).
Maybe there's something in the BIOS you can change to disable this 'feature' ?
well, if anyone else does a search on this issue, here's a cool workaround to
put in your scripts,
while [ `cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq` != \
`cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq` ]
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq > \
Please try latest kernels.
This got fixed, Dave himself checked it in :)
The problem on these Dells is that BIOS lowers the frequency behind the kernels
back. Later on cpufreq core detects that the speed got out of sync and gets
Unfortunately first approach triggered a zero division in tsc update/sync on
longhaul therefore it is this bunch of patches:
2006-02-02 [CPUFREQ] Check whether driver init did not initialize ...
2006-02-02 [CPUFREQ] Check for not initialized freq on cpufreq ...
2006-01-27 [CPUFREQ] Get rid of userspace policy struct, make ...
2006-01-26 [CPUFREQ] _PPC frequency change issues
The latest patch that I posted on cpufreq list today is also related, but you
only should run into this if the governor is changed from userspace while
cpufreq is limited (this one also affect all other machines doing cpufreq
*** Bug 6370 has been marked as a duplicate of this bug. ***
*** Bug 6376 has been marked as a duplicate of this bug. ***
Sorry for replying again. I am new to Linux and mailing lists.
Currently, I am using the 2.6.15-suspend2-r8 kernel from Gentoo. This kernel has
already the _PPC frequency change issues patch, I think.
But which kernel version has already have all these patches included? or where
can I find these patches and apply them by hand?
I hope to resolve these problems soon. And thanks to Thomas for providing the