[ltp] [patch] ACPI: fix cpufreq regression
Henrique de Moraes Holschuh
linux-thinkpad@linux-thinkpad.org
Thu, 25 Jan 2007 20:04:00 -0200
--envbJBWh7q8WU6mo
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
This is the patch Len is talking about. Did any of you guys using a multi-core
ThinkPad and 2.6.19.2 also noticed the bug in cpufreq this patch is supposed
to fix?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--envbJBWh7q8WU6mo
Content-Type: message/rfc822
Content-Disposition: inline
X-Original-To: hmh@khazad-dum.debian.net
Delivered-To: hmh@khazad-dum.debian.net
Received: from localhost (localhost [127.0.0.1])
by localhost.khazad-dum.debian.net (Postfix) with ESMTP id E43A32806D
for <hmh@khazad-dum.debian.net>; Tue, 23 Jan 2007 14:20:18 -0200 (BRST)
X-Virus-Scanned: Debian amavisd-new at khazad-dum.debian.net
Received: from khazad-dum.debian.net ([127.0.0.1])
by localhost (khazad-dum.debian.net [127.0.0.1]) (amavisd-new, port 10024)
with LMTP id viJvULloeS0f for <hmh@khazad-dum.debian.net>;
Tue, 23 Jan 2007 14:20:10 -0200 (BRST)
Received: by khazad-dum.debian.net (Postfix, from userid 1000)
id CBF4828092; Tue, 23 Jan 2007 14:20:10 -0200 (BRST)
Received: from mail.messagingengine.com (66.111.4.52) by
khazad-dum.debian.net with IMAP4-SSL; 23 Jan 2007 16:20:10 -0000
Received: from mx6.internal (mx6.internal [10.202.2.205])
by store20m.internal (Cyrus v2.3.7-fmsvn9682) with LMTPA;
Tue, 23 Jan 2007 11:19:39 -0500
X-Sieve: CMU Sieve 2.3
X-Spam-source: Country='US', FromHeader='de', MailFrom='org'
X-Delivered-to: hmh@hmh.eng.br
Received: from vger.kernel.org (vger.kernel.org [209.132.176.167])
by mx1.messagingengine.com (Postfix) with ESMTP id 9EABF26FF95
for <hmh@hmh.eng.br>; Tue, 23 Jan 2007 11:16:40 -0500 (EST)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S933037AbXAWQQj (ORCPT <rfc822;hmh@hmh.eng.br>);
Tue, 23 Jan 2007 11:16:39 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933042AbXAWQQj
(ORCPT <rfc822;linux-acpi-outgoing>);
Tue, 23 Jan 2007 11:16:39 -0500
Received: from cantor.suse.de ([195.135.220.2]:59701 "EHLO mx1.suse.de"
rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
id S933037AbXAWQQi (ORCPT <rfc822;linux-acpi@vger.kernel.org>);
Tue, 23 Jan 2007 11:16:38 -0500
Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.suse.de (Postfix) with ESMTP id D3B03124E2;
Tue, 23 Jan 2007 17:16:36 +0100 (CET)
Subject: [Fwd: Fwd: [patch] ACPI: fix cpufreq regression]
From: Thomas Renninger <trenn@suse.de>
Reply-To: trenn@suse.de
To: Stable <Stable@kernel.org>
Cc: Len Brown <lenb@kernel.org>,
linux-acpi <linux-acpi@vger.kernel.org>,
Dave Jones <davej@redhat.com>, mingo@elte.hu
Content-Type: text/plain
Organization: Novell/SUSE
Date: Tue, 23 Jan 2007 17:16:26 +0100
Message-Id: <1169568986.18157.194.camel@d36.suse.de>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.2
Content-Transfer-Encoding: 7bit
Sender: linux-acpi-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-acpi@vger.kernel.org
Can this one also be added to 2.6.19.X kernel.
Beside the Thinkpad it also seems to fix other system:
http://bugzilla.kernel.org/show_bug.cgi?id=7859
Thanks,
Thomas
-------- Forwarded Message --------
From: Len Brown <lenb@kernel.org>
To: linux-acpi@vger.kernel.org
Subject: Fwd: [patch] ACPI: fix cpufreq regression
Date: Tue, 16 Jan 2007 22:13:14 -0500
> nobody else with a T60 noticed this since November?
I expect it's because the patch which caused the regression,
seemed to be rather safe and came in quite late...
---------- Forwarded Message ----------
Subject: [patch] ACPI: fix cpufreq regression
Date: Tuesday 16 January 2007 12:09
From: Ingo Molnar <mingo@elte.hu>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, Dave Jones <davej@redhat.com>, Linus Torvalds <torvalds@osdl.org>, Len Brown <lenb@kernel.org>
Subject: [patch] ACPI: fix cpufreq regression
From: Ingo Molnar <mingo@elte.hu>
recently cpufreq support on my laptop (Lenovo T60) broke completely:
when it's plugged into AC it would never go higher than 1 GHz - neither
1.3 GHz nor 1.83 GHz is possible - no matter which governor (userspace,
speed or ondemand) is used.
after some cpufreq debugging i tracked the regression back to the
following (totally correct) bug-fix commit:
commit 0916bd3ebb7cefdd0f432e8491abe24f4b5a101e
Author: Dave Jones <davej@redhat.com>
Date: Wed Nov 22 20:42:01 2006 -0500
[PATCH] Correct bound checking from the value returned from _PPC method.
this bugfix, which makes other laptops work, made a previously hidden
(BIOS) bug visible on my laptop.
The bug is the following: if the _PPC (Performance Present Capabilities)
optional ACPI object is queried /after/ bootup then the BIOS reports an
incorrect value of '2'.
My laptop (Lenovo T60) has the following performance states supported:
0: 1833000
1: 1333000
2: 1000000
Per ACPI specification, a _PPC value of '0' means that all 3 performance
states are usable. A _PPC value of '1' means states 1 .. 2 are usable, a
value of '2' means only state '2' (slowest) is usable.
now, the _PPC object is optional, and it also comes with notification.
Furthermore, when a CPU object is initialized, the _PPC object is
initialized as well. So the following evaluation of the _PPC object is
superfluous:
[<c028ba5f>] acpi_processor_get_platform_limit+0xa1/0xaf
[<c028c040>] acpi_processor_register_performance+0x3b9/0x3ef
[<c0111a85>] acpi_cpufreq_cpu_init+0xb7/0x596
[<c03dab74>] cpufreq_add_dev+0x160/0x4a8
[<c02bed90>] sysdev_driver_register+0x5a/0xa0
[<c03d9c4c>] cpufreq_register_driver+0xb4/0x176
[<c068ac08>] acpi_cpufreq_init+0xe5/0xeb
[<c010056e>] init+0x14f/0x3dd
and this is the point where my laptop's BIOS returns the incorrect value
of '2'. Note that it has not sent any notification event, so the value
is probably not really intentional (possibly spurious), and Windows
likely doesnt query it after bootup either. Maybe the value is kept at
'2' normally, and is only set to the real value when a true asynchronous
event (such as AC plug event, battery switch, etc.) occurs.
So i /think/ this is a grey area of the ACPI spec: per the letter of the
spec the _PPC value only changes when notified, so there's no reason to
query it after the system has booted up. So in my opinion the best (and
most compatible) strategy would be to do the change below, and to not
evaluate the _PPC object in the acpi_processor_get_performance_info()
call, but only evaluate it if _PPC is present during CPU object init, or
if it's notified during an asynchronous event. This change is more
permissive than the previous logic, so it definitely shouldnt break any
existing system.
This also happens to fix my laptop, which is merrily chugging along at
1.83 GHz now. Yay!
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
drivers/acpi/processor_perflib.c | 4 ----
1 file changed, 4 deletions(-)
Index: linux/drivers/acpi/processor_perflib.c
===================================================================
--- linux.orig/drivers/acpi/processor_perflib.c
+++ linux/drivers/acpi/processor_perflib.c
@@ -322,10 +322,6 @@ static int acpi_processor_get_performanc
if (result)
return result;
- result = acpi_processor_get_platform_limit(pr);
- if (result)
- return result;
-
return 0;
}
-
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/
-------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--envbJBWh7q8WU6mo--