Most recent kernel where this bug did not occur: unknown Distribution: ubuntu dapper Hardware Environment: Dell inspiron 9300 Inetl Pentium M 1.73 using centrino-speedstep Software Environment: ubuntu dapper gcc 4.0.3 Problem Description: when ac cord is pulled (even in single user mode, or with init=/bin/sh) /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 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 pull plug # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq repeat last step until it eventually goes back to the full frequency and stays there. 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 http://rtr.ca/dell_i9300/kernel/latest/
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' ?
damn hardware! 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` ] do cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq > \ /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq sleep 1; done
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 confused. 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 limitations).
*** 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 patches.