Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: RE: cpufreq stops working after a while
Date: Fri, 11 Aug 2006 14:08:32 -0700
Message-ID: <EB12A50964762B4D8111D55B764A84546F8F4F@scsmsx413.amr.corp.intel.com>
Thread-Topic: cpufreq stops working after a while
thread-index: Aca9hQM833Lc6Ni/Tt2we4qFNF31CwABHg4A
From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
To: "Mark Lord" <lkml@rtr.ca>, "Dave Jones" <davej@redhat.com>
Cc: "Linux Kernel" <linux-kernel@vger.kernel.org>,
       "Andrew Morton" <akpm@osdl.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2641
Lines: 67

 

>-----Original Message-----
>From: Mark Lord [mailto:lkml@rtr.ca] 
>Sent: Friday, August 11, 2006 1:30 PM
>To: Dave Jones
>Cc: Pallipadi, Venkatesh; Linux Kernel; Andrew Morton
>Subject: Re: cpufreq stops working after a while
>
>Pallipadi, Venkatesh wrote:
>>> Dave Jones wrote:
>>>> boot with cpufreq.debug=7, and capture dmesg output after it fails
>>>> to transition.  This might be another manifestation of the 
>mysterious
>>>> "highest frequency isnt accessable" bug, that seems to come from
>>>> some recent change in acpi.
>..
>> You also need to configure in CONFIG_CPU_FREQ_DEBUG
>
>Thanks, Venki!
>
>Okay, here's the tail end of the trace, in which (search for "max")
>one can see the top frequency limit being downgraded.
>
>But, by whom, and why ??
>And what's with these requests for oddball frequencies ("685714"),
>or is that just normal approximation within the governor?
>
>
>[  853.228000] cpufreq-core: updating policy for CPU 0
>[  853.228000] cpufreq-core: Warning: CPU frequency out of 
>sync: cpufreq and timing core thinks of 1100000, is 800000 kHz.
>[  853.228000] cpufreq-core: notification 0 of frequency 
>transition to 800000 kHz
>[  853.228000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
>[  853.228000] cpufreq-core: notification 1 of frequency 
>transition to 800000 kHz
>[  853.228000] cpufreq-core: scaling loops_per_jiffy to 
>3195840 for frequency 800000 kHz
>[  853.228000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
>[  853.228000] cpufreq-core: setting new policy for CPU 0: 
>600000 - 1100000 kHz
>[  853.228000] freq-table: request for verification of policy 
>(600000 - 1100000 kHz) for cpu 0
>[  853.228000] freq-table: verification lead to (600000 - 
>1100000 kHz) for cpu 0
>[  853.228000] freq-table: request for verification of policy 
>(600000 - 800000 kHz) for cpu 0
>[  853.228000] freq-table: verification lead to (600000 - 
>800000 kHz) for cpu 0
>[  853.228000] cpufreq-core: new min and max freqs are 600000 
>- 800000 kHz
>[  853.228000] cpufreq-core: governor: change or update limits
>[  853.228000] cpufreq-core: __cpufreq_governor for CPU 0, event 3

Looks like there are thermal events happening that is causing CPU limits
to reduce. Are you running anything on the CPU when this happens. Is
there a thermal interface in /proc/acpi that can give you the current
temperature of the system?

Thanks,
Venki
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/