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.
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.
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
OK, it _isnt_ doing thermal throttling at the moment. What does cpufreq-info (part of cpufrequtils) say when such a situation exists?
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. :-(
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
Are these problems still present in 2.6.20-rc7? Thanks.
Please reopen this bug if it's still present with kernel 2.6.20.