From owner-freebsd-current@FreeBSD.ORG Thu Nov 8 23:20:36 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D9EC16A503; Thu, 8 Nov 2007 23:20:36 +0000 (UTC) (envelope-from mail@maxlor.com) Received: from popeye1.ggamaur.net (popeye1.ggamaur.net [213.160.40.50]) by mx1.freebsd.org (Postfix) with ESMTP id F16AF13C480; Thu, 8 Nov 2007 23:20:34 +0000 (UTC) (envelope-from mail@maxlor.com) Received: from maxlor.mine.nu (c-82-192-240-247.customer.ggaweb.ch [82.192.240.247]) by popeye1.ggamaur.net (8.13.7/8.13.7/Submit) with ESMTP id lA8N5R3P058712; Fri, 9 Nov 2007 00:05:28 +0100 (CET) (envelope-from mail@maxlor.com) Received: from localhost (unknown [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id 6F7D72E2AC; Fri, 9 Nov 2007 00:05:13 +0100 (CET) X-Virus-Scanned: amavisd-new at atlantis.intranet Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (atlantis.intranet [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3lJDT6xbtKN; Fri, 9 Nov 2007 00:05:12 +0100 (CET) Received: from mini.intranet (mini.intranet [10.0.0.17]) by maxlor.mine.nu (Postfix) with ESMTP id 93D9A2E2AB; Fri, 9 Nov 2007 00:05:12 +0100 (CET) From: Benjamin Lutz To: Simon Barner Date: Fri, 9 Nov 2007 00:05:18 +0100 User-Agent: KMail/1.9.7 References: <472E9D0B.5080409@csub.edu> <47334C71.1010102@nortel.com> <20071108224313.GA1927@dose.local.invalid> In-Reply-To: <20071108224313.GA1927@dose.local.invalid> X-Face: $Ov27?7*N,h60fIEfNJdb!m,@#4T/d; 1hw|W0zvsHM(a$Yn6BYQ0^SEEXvi8>D`|V*F"=?utf-8?q?=5F+=0A=09R2?=@Aq>+mNb4`,'[[%z9v0Fa~]AD1}xQO3|>b.z&}l#R-_(P`?@Mz"kS; XC>Eti,i3>%@=?utf-8?q?g=3F=0A=094f?=,\c7|Ghwb&ky$b2PJ^\0b83NkLsFKv|smL/cI4UD%Tu8alAD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3315018.dH3f6CITOK"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711090005.21842.mail@maxlor.com> X-Scanned-By: MIMEDefang 2.62 on 213.160.40.60 Cc: Matus Harvan , freebsd-current@freebsd.org Subject: Re: powerd adaptive mode latching X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2007 23:20:36 -0000 --nextPart3315018.dH3f6CITOK Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 08 November 2007 23:43:13 Simon Barner wrote: > > > Please see kern/114722. The patch from the PR works fine with my > > > T61 (T7300). > > > > > > Funny enough, I contacted re@ to get this into 7.0 only two > > > minutes ago. > > > > > > For the archives, the similar bug described in bin/117375 already > > > seems to be adressed in RELENG_7. > > > > both pr's are open .. and > > > > releng_7 and head are both at v 1.26 of acpi_perf.c > > > > so, no it's not fixed, *anywhere*. :) > > It's true that both PRs are still open, but: > > 1) kern/114722 should fix your problem (CPUFREQ_CMP takes care of > almost identical frequencies). Have you already had a chance to > verify that? > > 2) bin/117375 talks about exactly identical frequencies, which should > be handled by acpi_perf.c (1.26, line 303-306). However, the reporter > (Cc'ed) of that PR runs FreeBSD 6.2-p8 which already contains the > removal of duplicate entries (MFC from acpi_perf.c 1.24). > > @Benjamin Lutz: Could you please check if the problem still > exists, and if so, whether the patch from kern/114722 fixes it? Before patch (still on 6.2-RELEASE-p8): dev.cpu.0.freq_levels: 2100/15000 2100/13720 1890/11360 1050/5531 So yes, the problem still exists. After patch: dev.cpu.0.freq_levels: 2100/15000 2100/13720 1890/11360 1050/5531 And it seems the patch doesn't fix it. Btw, looking at that part (the for loop around line 303) of acpi_perf.c=20 in isolation, it just occurred to me that the check for duplicate=20 entries fails if the duplicate entries are the last in the list, which=20 would probably prevent powerd from scaling the CPU back up. Or maybe=20 I'm wrong, I haven't really looked at the rest of the code. Thanks for working on this! Cheers Benjamin --nextPart3315018.dH3f6CITOK Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBHM5YuzZEjpyKHuQwRAqfDAJ4s1tx0KGvjcjKEdOI8nv9RFo9bowCfeW2F YztcXXUWi0bPIUj7UYHB6/g= =juXD -----END PGP SIGNATURE----- --nextPart3315018.dH3f6CITOK--