Bug 5353

Summary: cpufreq_conservative: cpu always in slowest mode even under high load
Product: Power Management Reporter: Markus Schaub (linux)
Component: cpufreqAssignee: cpufreq (cpufreq)
Status: REJECTED INSUFFICIENT_DATA    
Severity: normal CC: akpm, bunk, linux
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.13-rc7 Subsystem:
Regression: --- Bisected commit-id:
Attachments: cat /proc/acpu/processor/CPU/*

Description Markus Schaub 2005-10-03 08:21:24 UTC
Most recent kernel where this bug did not occur: don't know
Distribution:
Hardware Environment: IBM Thinkpad T43, Pentium M
Software Environment: speedstep_centrino
Problem Description:
After serveral hours under high cpu load (i.e. coding videos with mencoder) the
system switches to the lowest possible cpu frequency (indicated by
/sys/devices/.../cpufreq/scaling_cur_freq or by low frame rate in video coder).
Then changing scaling_governor to performance doesn't change anything, the cpu
frequency stays at the lowest possible value. Only reboot fixes this.

Steps to reproduce:
$ modprobe cpufreq_conservative
$ modprobe speedstep_centrino
then wait a long time :-)
The Problem occurs very seldomly, about three times in the last months.
Comment 1 Dominik Brodowski 2005-11-15 13:44:04 UTC
Possibly thermal management kicks in -- this means the CPU frequency is lowered
by  the BIOS using ACPI callbacks -- but doesn't restore normal behavior again
once the overheating disappears. That's my guess... if it happens again, please
save the output of
cat /proc/acpi/processor/CPU0/*
and attach it here to this bug.
Comment 2 Markus Schaub 2005-12-19 11:38:09 UTC
Created attachment 6858 [details]
cat /proc/acpu/processor/CPU/*

Same situation as in the bug ddescription , machine is pretty cold
Kernel Version is now 2.6.15-rc2
Comment 3 Dominik Brodowski 2006-01-10 09:31:45 UTC
OK, it _isnt_ doing thermal throttling at the moment. What does cpufreq-info
(part of cpufrequtils) say when such a situation exists?
Comment 4 Gunter Ohrner 2006-01-10 14:11:56 UTC
Mh, I thought conservative was completely broken. To be honest, on both of my 
machines - a Celeron M notebook and my AMD64 Winchester - switching to 
conservative with standard settings causes the CPU to immediately enter the 
lowest speed setting and never changing back, independant of the load. Thus 
I'm using ondemand which works flawlessly. (Both 2.6.13.x and 1.6.14.x vanilla 
kernel versions.) 
 
Hoping the bug isn't just sitting in front of my keyboard, is there any way I 
could help to debug the problems? Patching or rebuilding the kernel would be 
no problem if neccessary, however I'm just in the middle of preparing for an 
examn and have not too much time to fiddle with tings myself ATM. :-( 
Comment 5 Carl Michal 2006-01-26 13:16:54 UTC
I've seen something that may be related on a Dell Inspiron 630m.

When the plug gets pulled to switch to batteries, scaling_max_frequency drops to
the lowest speed (and usually the cpu speed drops as well, but not always - so
sometimes the cpu speed is actually faster than the policy limits).  Then about
15 seconds later a CPU acpi event occurs and the scaling_max_frequency pops back
to where it was.  I don't think this is due to any user space tools.  It happens
exactly the same way if laptop_mode is running or not and if acpid is running or
not.

If I try to set scaling_max_frequency to some other frequency value with 
echo -n (or with cpufreq-set) the new value is ignored.  After the acpi CPU
event, exactly the same command does its job.

This happens with any of the governors running (tried userspace, conservative,
performance). 

Sometimes conservative seems to get confused - the only consistent way I've seen
to make it confused is to start to hibernate, and then pull the plug.  After
starting up on ac (using swsusp2) the governor won't make any changes to the
speed.  Pulling the plug actually does seem to get it unconfused.

I've tried speedstep_centrino with freq_table as well as acpi_cpufreq and see
the same behaviour either way.

I have 2.6.15 with swsusp2
Comment 6 Andrew Morton 2007-01-31 01:20:15 UTC
Are these problems still present in 2.6.20-rc7?

Thanks.
Comment 7 Adrian Bunk 2007-03-08 21:26:19 UTC
Please reopen this bug if it's still present with kernel 2.6.20.