From owner-freebsd-stable@FreeBSD.ORG Sun Mar 28 01:54:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 775B0106566C; Sun, 28 Mar 2010 01:54:52 +0000 (UTC) (envelope-from fbsd2@sstec.com) Received: from star.sstec.com (adsl-216-102-148-67.dsl.lsan03.pacbell.net [216.102.148.67]) by mx1.freebsd.org (Postfix) with ESMTP id 326BE8FC13; Sun, 28 Mar 2010 01:54:51 +0000 (UTC) Received: from main.sstec.com (main.sstec.com [192.168.74.8]) by star.sstec.com (8.13.8/8.13.8) with ESMTP id o2S1sgYv083127; Sat, 27 Mar 2010 18:54:46 -0700 (PDT) (envelope-from fbsd2@sstec.com) Message-Id: <5.2.1.1.2.20100327165629.032357b0@mail.sstec.com> X-Sender: X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 27 Mar 2010 18:53:21 -0700 To: Ian Smith , Jeremy Chadwick From: John Long In-Reply-To: <20100327153102.X30338@sola.nimnet.asn.au> References: <20100326091447.GA91547@icarus.home.lan> <5.2.1.1.2.20100324134153.032459d8@mail.sstec.com> <1269310984.00232724.1269300005@10.7.7.3> <1269310984.00232724.1269300005@10.7.7.3> <5.2.1.1.2.20100324134153.032459d8@mail.sstec.com> <5.2.1.1.2.20100325235505.031e8338@mail.sstec.com> <20100326091447.GA91547@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Alexander Motin , FreeBSD-STABLE Mailing List Subject: Re: Powerd and est / eist functionality X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 01:54:52 -0000 At 10:35 PM 3/26/2010, Ian Smith wrote: >On Fri, 26 Mar 2010, Jeremy Chadwick wrote: > >[ leaving the MB monitoring stuff alone for your expert attention :-] > > > > It jumped up in vcore a little there with powerd. C1E and C2E which > > > include P-states are what I am really after and I think that the > > > bios by itself provides those changes better than any other changes > > > in these settings. > > > > ...and this would fall under the est(4) subset driver for cpufreq(4). > >Just checking, I know nothing about these so far, but are you suggesting >that John having C1E and C2E enabled in BIOS may be affecting ACPI/EST >detection, and that things may be different were these disabled? No sir. Detection appears to be a function of the signals that are provided by the mbd regardless of bios settings. As per earlier msgs, I originally found out that powerd actually increased the TDP of the system at the wall by about 3 watts. That turning off the bios settings for c1e, c2e and eist raised the power a little and with powerd it was still higher than with just bios factors on and no powerd. All the rest is just discovery as to why this anomaly was so. It seems that ACPI is just not fully functional for this motherboard and if est does work on other recent mbds then that would be because of the acpi working better for them as the hard coded est tables are a bit old. From what I see, est takes tables primary and acpi fallback. powerd takes est primary and thermal fallback (acpi may be in there too, forgot now). powerd and thermal is not viable for lowering power usage at very low cpu rates. It merely provides a phantom crutch until one does realize it does not truly work, in my case anyway. We need to use the P-states which lower voltage and true freq, in order to lower tdp sucessfully, from what I see. > >If that's not what you meant, could you expand a little? > >John: you may want to explore where this comes together in kern_cpu.c >where you'll see those cpufreq debugging messages you quoted. kern_cpu.c looks to be the mech for reading or setting the freq. In there they mention that using an absolute freq is preferable to the artificial freq with lengthened clocks because then the voltage is often changed relative thereto. Where the voltage is changed is my quest. No where in there nor src/sys/kern do I see a ref for p-states and only in that file is voltage referenced. Therefore the change in voltage as a function of frequency must be auto determinant in another place and probably the bios as my guess so far. Further looking I see ichss.c in /usr/src/sys/dev/cpufreq (dev not i386 dir) where voltage is referenced. No other refs of votage I notice other than batt etc and no ref to pstate nor p-state at all in src/sys. Personally, I deem p-states to be key therefore I may assume that they are left to lower level bios routines relative to freq unless I am missing something here. Considering the absolute freq is preferred over the artificial freq, that is a remnant of powerd (when it falls back to just thermal), and appears to be a requisite for the lower level routines in order to change p-states, leads me back to getting est to load proper. Therefore I should pursue the tables part of its detection, if I continue digging into things that are over my head.. Some of >the more gritty documentation may be found browsing with something like: >% less /sys/{sys,kern,amd64/include}/*cpu*.[ch] Things that should be left to the pros that have been wading this ocean of code for years.. :-) thanks again, John > >cheers, Ian