Bug 5353

Summary:	cpufreq_conservative: cpu always in slowest mode even under high load
Product:	Power Management	Reporter:	Markus Schaub (linux)
Component:	cpufreq	Assignee:	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.