From owner-freebsd-acpi@FreeBSD.ORG Wed May 3 13:14:25 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C8A116A403 for ; Wed, 3 May 2006 13:14:25 +0000 (UTC) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFBDF43D48 for ; Wed, 3 May 2006 13:14:24 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1FbHB9-0008Qj-00; Wed, 03 May 2006 15:14:07 +0200 Date: Wed, 3 May 2006 15:14:07 +0200 To: ales.rom@kabelnet.net Message-ID: <20060503131407.GA31815@poupinou.org> References: <44524200.8050504@kabelnet.net> <44525C0B.8090802@root.org> <44526F8E.70502@kabelnet.net> <20060502115433.GD16180@poupinou.org> <44585CFF.50305@kabelnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44585CFF.50305@kabelnet.net> User-Agent: Mutt/1.5.9i From: Bruno Ducrot Cc: freebsd-acpi@FreeBSD.org Subject: Re: powerd on Gericom Webgine XL not running quite well X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 13:14:25 -0000 On Wed, May 03, 2006 at 09:34:23AM +0200, ales.rom@kabelnet.net wrote: > Bruno Ducrot pravi: > >On Fri, Apr 28, 2006 at 07:39:58PM +0000, Ales wrote: > >>Nate Lawson pravi: > >>>Ales wrote: > >>>>Powerd is running, but when it comes to maximum frequency speed it > >>>stays > >>>>there. The example of powerd -v is here: > >>>> > >>>># powerd -v > >>>>idle time < 65%, increasing clock speed from 798 MHz to 931 MHz > >>>>idle time > 90%, decreasing clock speed from 1064 MHz to 997 MHz > >>>>idle time > 90%, decreasing clock speed from 931 MHz to 864 MHz > >>>>idle time < 65%, increasing clock speed from 931 MHz to 1064 MHz > >>>>idle time > 90%, decreasing clock speed from 1197 MHz to 1197 MHz > >>>>idle time > 90%, decreasing clock speed from 1197 MHz to 1197 MHz > >>>>idle time > 90%, decreasing clock speed from 1197 MHz to 1197 MHz > >>>>idle time > 90%, decreasing clock speed from 1197 MHz to 1197 MHz > >>>>. > >>>>. > >>>>. > >>>>So, it looks that powerd can increase and decrease CPU speed until it > >>>>reaches maximum. If I manualy change frequency with sysctl, frequency > >>>>can go down again. > >>>> > >>>>sysctl dev.cpu.0.freq=800 > >>>>dev.cpu.0.freq: 1197 -> 798 > >>>>dev.cpu.0.%desc: ACPI CPU > >>>>dev.cpu.0.%driver: cpu > >>>>dev.cpu.0.%location: handle=\_PR_.CPU1 > >>>>dev.cpu.0.%pnpinfo: _HID=none _UID=0 > >>>>dev.cpu.0.%parent: acpi0 > >>>>dev.cpu.0.freq: 1197 > >>>>dev.cpu.0.freq_levels: 1197/35004 1197/35004 1197/35004 1197/35004 > >>>>1197/35004 1064/29004 997/25291 931/23595 864/21910 798/20224 > >>>> > >>>>dev.powernow.0.%desc: PowerNow! K7 > >>>>dev.powernow.0.%driver: powernow > >>>>dev.powernow.0.%parent: cpu0 > >>>>dev.powernow.0.freq_settings: 1197/35004 1197/35004 1197/35004 > >>>>1197/35004 1197/35004 1064/29004 997/25291 931/23595 864/21910 > >>>>798/20224 > >>>Something is really screwy with your powernow settings. It's > >>>reporting 5 settings with all the same freq (1197, see above). So > >>>powerd is decreasing your frequency, it's just decreasing from 1197 to > >>>1197 (no change). > > > >Indeed. > > > >>The way to figure this out is to add some debugging prints to the > >>powernow table detection algorithm to see why this is occurring. Also, > >>you could try not loading cpufreq.ko and see if acpi_perf gives more > >>accurate settings. Just make sure acpi is loaded to get acpi_perf. > > > >I'm unaware of any athlon systems starting with K7 cores for which > >acpi_perf alone will work. But since the power comsuption is displayed, > >I believe powernow will use acpi tables in order to get p-states. > >I think therefore the AML is a little bogus, more specifically that > >there is duplicate entries for 1197MHz. > > > >If the OP could give an URL to Gericom_Webgine_XL.asl, generated by > >acpidump -d -t > Gericom_Webgine_XL.asl > > > >then I should be able to verify if that statement is true. > > > >> > The file is here: http://www.p-rom.si/Gericom_Webgine_XL.asl Thanks. As I supposed, there are duplicate entries for the max p-state: Scope (\_PR) { Processor (CPU1, 0x01, 0x00000810, 0x06) { ... Name (_PSS, Package (0x0A) { Package (0x06) { 0x000004B0, 0x000088BC, 0x0000007D, 0x0000007D, 0x009C416C, 0x0000016C }, Package (0x06) { 0x000004B0, 0x000088BC, 0x0000007D, 0x0000007D, 0x009C416C, 0x0000016C }, Package (0x06) { 0x000004B0, 0x000088BC, 0x0000007D, 0x0000007D, 0x009C416C, 0x0000016C }, This package is duplicated 5 times and correspond to the max one. ... ... } our acpi_perf driver does not handle this situation. I think this patch (can not compile test, I don't have a FreeBSD handy ATM) should fix your issue (minus stupid mistake I may introduce). > > As I said in one of my previus messages: > If I change POWERNOW_MAX_STATES in powernow.c from 16 to 7 (I belive it > is the number of states on my proc) everything works fine!!! I know it > is stupid solution, but I do not know anything about C/C++ programming. > Sorry. The method CPUFREQ_DRV_SETTINGS() from acpi_perf give 10 p-states, not 7, therefore it failed, and pn_decode_acpi() fail. Legacy bios tables are used instead of those given by ACPI via pn_decode_pst() which return only 6 p-states. You can see the power consuption for each states is "-1" in that case because I dont know how to compute them. > dev.powernow.0.freq_settings: 1197/-1 1064/-1 997/-1 931/-1 864/-1 798/-1 > > Another thing. I belive that 1 frequency here is missing. > (8,5x133MHz=1133MHz) It should be there because we have FSB=133, multi=6 > to 9 in 0.5 step. Aparently the bios writer tell you 8.5 multiplier is not supported. You should always trust the bios writer (ahem) :) --- src/sys/dev/acpica/acpi_perf.c~ 2006-05-03 14:49:35.000000000 +0200 +++ src/sys/dev/acpica/acpi_perf.c 2006-05-03 14:50:37.000000000 +0200 @@ -299,6 +299,12 @@ acpi_perf_evaluate(device_t dev) sc->px_states[count].core_freq >= 0xffff) continue; + /* Check for duplicate entries */ + if (count > 0 && + sc->px_states[count - 1].core_freq == + sc->px_states[count].core_freq) + continue; + count++; } sc->px_count = count; -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care.