From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Lord Subject: Re: cpufreq stops working after a while Date: Fri, 11 Aug 2006 15:10:16 -0400 Message-ID: <44DCD618.2040700@rtr.ca> References: <44DCCB96.5080801@rtr.ca> <20060811114631.4a699667.akpm@osdl.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20060811114631.4a699667.akpm@osdl.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: cpufreq-bounces@lists.linux.org.uk Errors-To: cpufreq-bounces+glkc-cpufreq=m.gmane.org+glkc-cpufreq=m.gmane.org@lists.linux.org.uk Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Andrew Morton Cc: Linux Kernel , cpufreq@www.linux.org.uk Andrew Morton wrote: > On Fri, 11 Aug 2006 14:25:26 -0400 > Mark Lord wrote: > >> One of my notebooks (Dell Latitude X1) has a 1.1GHz Pentium-M ULV processor. >> This chip can change CPU speeds from 600 -> 800 -> 1100 Mhz. >> >> I use speedstep-centrino with it, and after boot all is usually okay. >> But after a few hours of operation, it stops shifting to the highest frequency >> even under continuous 100% load (or not). Eventually it gets stuck at 600Mhz >> and stays there until I reboot. >> >> Sometimes rebooting doesn't even restore it. >> >> /sys/devices/system/cpu/cpu0/cpufreq is all very normal looking, >> showing the available frequencies and other info. All of the attribs >> there look fine, except for "scaling_max_freq", which is what seems >> to gradually get set smaller. For instance, right now it is set to 800000, >> and it won't let me change it (echo 11000000 > scaling_max_freq has no effect. >> >> WHY? > > cpufreq seems to have relatively frequent problems. > >> And how can I fix it? > > You could start by telling us which kernel versions are affected ;) Mmm.. since it appears to be related, kbuild dumps this out when building the kernel: WARNING: drivers/acpi/processor.o - Section mismatch: reference to .init.data: from .text between 'acpi_processor_power_init' (at offset 0xf29) and 'acpi_processor_cst_has_changed' A possible source for the bug, or total red herring ?