From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758975AbZCSGDx (ORCPT ); Thu, 19 Mar 2009 02:03:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752936AbZCSGDn (ORCPT ); Thu, 19 Mar 2009 02:03:43 -0400 Received: from mail-gx0-f208.google.com ([209.85.217.208]:47746 "EHLO mail-gx0-f208.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752014AbZCSGDm (ORCPT ); Thu, 19 Mar 2009 02:03:42 -0400 X-Greylist: delayed 373 seconds by postgrey-1.27 at vger.kernel.org; Thu, 19 Mar 2009 02:03:42 EDT DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; b=Wub+mnqX65vGoawGIX5PzseKYZOk/R2gL83didO9mqtZSSUIbZd1+LVkW5mWw7c2n8 Zda8z+SrEeggyIR9v86Llj/RQnoCK26hpPKINC2HalTpCu3fRdE2wWsX1KtlrCZp87g3 AK/HYxeYEDhTdhlU1WhpfQtSQo2vtVxvOkGtY= From: Dmitry Torokhov To: cpufreq@vger.kernel.org Subject: 2.6.29-rcX: wierd iteractions with CPUFREQ Date: Wed, 18 Mar 2009 22:57:21 -0700 User-Agent: KMail/1.11.1 (Linux/2.6.29-rc8; KDE/4.2.1; x86_64; ; ) Cc: linux-kernel@vger.kernel.org, davej@redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903182257.21691.dmitry.torokhov@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Something weird is happening with 2.6.29 - once my laptop starts heating up and fans come up it locks at 800MHz, but there are no valid thermal events. If I enable cpufreq debug I am getting the following (dump stack was added by myself to see where __cpufreq_set_policy is being called from): CPU0: setting new policy for CPU 0: 800000 - 2201000 kHz Pid: 220, comm: kacpi_notify Not tainted 2.6.29-rc8 #110 Call Trace: [] __cpufreq_set_policy+0x3a/0x210 [] cpufreq_update_policy+0x112/0x134 [] ? handle_update+0x0/0x38 [] acpi_processor_ppc_has_changed+0xc8/0xd1 [] ? acpi_bus_get_device+0x2a/0x3e [] acpi_processor_notify+0x64/0x10d [] ? _spin_unlock_irq+0x30/0x62 [] acpi_ev_notify_dispatch+0x64/0x70 [] acpi_os_execute_deferred+0x31/0x3e [] run_workqueue+0x108/0x21b [] ? run_workqueue+0xb6/0x21b [] ? acpi_os_execute_deferred+0x0/0x3e [] worker_thread+0xe5/0xf6 [] ? autoremove_wake_function+0x0/0x3d [] ? worker_thread+0x0/0xf6 [] kthread+0x4e/0x7b [] child_rip+0xa/0x20 [] ? finish_task_switch+0x0/0xca [] ? restore_args+0x0/0x30 [] ? kthread+0x0/0x7b [] ? child_rip+0x0/0x20 freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0 freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0 freq-table: request for verification of policy (800000 - 800000 kHz) for cpu 0 freq-table: verification lead to (800000 - 800000 kHz) for cpu 0 cpufreq-core: new min and max freqs are 800000 - 800000 kHz cpufreq-core: governor: change or update limits cpufreq-core: __cpufreq_governor for CPU 0, event 3 cpufreq-core: target for CPU 0: 800000 kHz, relation 1 freq-table: request for target 800000 kHz (relation: 1) for cpu 0 freq-table: target is 4 (800000 kHz, 4) cpufreq-core: notification 0 of frequency transition to 800000 kHz cpufreq-core: notification 1 of frequency transition to 800000 kHz As you can see for some reason the 2nd validation clams the frequency to 800 (although the first one done immediately before says that 2.2GHz is fine) and the system slows to a crawl. -- Dmitry