Bug 6331

Summary:	cpu frequency gets lowered by kernel when cord is pulled(init=bin/sh)
Product:	Power Management	Reporter:	Michal Palczewski (mike)
Component:	cpufreq	Assignee:	cpufreq (cpufreq)
Status:	REJECTED INVALID
Severity:	low	CC:	jean-marc.valin, stivani
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.16 from kernel.org	Subsystem:
Regression:	---	Bisected commit-id:

Description Michal Palczewski 2006-04-04 13:03:42 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
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.

Comment 1 Michal Palczewski 2006-04-04 13:21:03 UTC

forgot to mention I have all of the following patches on this page 
http://rtr.ca/dell_i9300/kernel/latest/

Comment 2 Dave Jones 2006-04-04 13:24:38 UTC

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' ?

Comment 3 Michal Palczewski 2006-04-04 13:48:52 UTC

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

Comment 4 Thomas Renninger 2006-04-04 13:59:57 UTC

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).

Comment 5 Thomas Renninger 2006-04-13 03:45:54 UTC

*** Bug 6370 has been marked as a duplicate of this bug. ***

Comment 6 Thomas Renninger 2006-04-13 03:50:06 UTC

*** Bug 6376 has been marked as a duplicate of this bug. ***

Comment 7 Stijn Van Nieuwenhuyse 2006-04-13 12:16:20 UTC

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.