From owner-freebsd-stable@FreeBSD.ORG Fri Mar 26 08:20:44 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 ECE681065670; Fri, 26 Mar 2010 08:20:43 +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 690098FC16; Fri, 26 Mar 2010 08:20:43 +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 o2Q8KcOe024439; Fri, 26 Mar 2010 01:20:41 -0700 (PDT) (envelope-from fbsd2@sstec.com) Message-Id: <5.2.1.1.2.20100325235505.031e8338@mail.sstec.com> X-Sender: X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 26 Mar 2010 01:20:19 -0700 To: Ian Smith From: John Long In-Reply-To: <20100326004840.M30338@sola.nimnet.asn.au> References: <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> 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: Fri, 26 Mar 2010 08:20:44 -0000 At 09:24 PM 3/25/2010, Ian Smith wrote: >On Wed, 24 Mar 2010, John Long wrote: > > At 11:27 PM 3/22/2010, Alexander Motin wrote: > > >John Long wrote: > > >> Hello, I am putting together a couple update servers. Went with c2d > > >> E7500 on gigabyte G41M-ES2L boards. fbsd 8.0 release generic (so far) > > >> amd64, 1g mem, 1tb wd cavier blk, fresh system. > > >> My Kill-a-watt shows 41 watts idle and when I enable powerd then it > > >> climbs to 43 watts idle. > >I'm interested in this apparently strange finding. Can you show sysctl >dev.cpu after boot but before running powerd, and after starting powerd? > >I wonder particularly what dev.cpu.o.freq is before running powerd, ie >whether it boots up at full speed? We've seen some that haven't, >perhaps influenced by BIOS settings? Bios is most recent re their site. F6 I believe. boots to same 41 watts. %sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 2933 dev.cpu.0.freq_levels: 2933/-1 2566/-1 2199/-1 1833/-1 1466/-1 1099/-1 733/-1 366/-1 dev.cpu.0.cx_supported: C1/1 C2/1 C3/150 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 500us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/1 C2/1 C3/150 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 500us %powerd -n adp about 3 secs later %sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1833 dev.cpu.0.freq_levels: 2933/-1 2566/-1 2199/-1 1833/-1 1466/-1 1099/-1 733/-1 366/-1 dev.cpu.0.cx_supported: C1/1 C2/1 C3/150 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 500us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/1 C2/1 C3/150 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 500us wait about 10 more sec and it is down to min freq and pwr is up to 44 watts. %sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 366 dev.cpu.0.freq_levels: 2933/-1 2566/-1 2199/-1 1833/-1 1466/-1 1099/-1 733/-1 366/-1 dev.cpu.0.cx_supported: C1/1 C2/1 C3/150 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 500us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/1 C2/1 C3/150 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 500us >Turning on debug.cpufreq.verbose and hw.acpi.verbose may add clues? Either of the above makes no change in dev.cpu out but sysctl -a gets really noisy in places cpufreq: dup done, inserting new level 1833 after 2199 cpufreq: expand set added rel setting 62% to 1833 level cpufreq: dup set considering derived setting 1466 cpufreq: removed last relative driver: p4tcc1 cpufreq: dup done, inserting new level 1466 after 1833 cpufreq: expand set added rel setting 50% to 1466 level cpufreq: dup set considering derived setting 1099 cpufreq: removed last relative driver: p4tcc1 cpufreq: dup done, inserting new level 1099 after 1466 cpufreq: expand set added rel setting 37% to 1099 level cpufreq: dup set considering derived setting 733 cpufreq: removed last relative driver: p4tcc1 cpufreq: dup done, inserting new level 733 after 1099 cpufreq: expand set added rel setting 25% to 733 level cpufreq: dup set considering derived setting 366 cpufreq: removed last relative driver: p4tcc1 cpufreq: dup done, inserting new level 366 after 733 cpufreq: expand set added rel setting 12% to 366 level cpufreq: setting rel freq 10000 on p4tcc1 (cpu 1) cpufreq: get returning known freq 2933 cpufreq: get returning known freq 2933 cpufreq: get returning known freq 2933 cpufreq: get returning known freq 2933 cpufreq: get returning known freq 2933 cpufreq: get returning known freq 2933 cpufreq: get returning known freq 2933 cpufreq: get returning known freq 2933 cpufreq: get returning known freq 2933 cpufreq: get returning known freq 2933 cpufreq: get returning known freq 2933 cpufreq: get returning known freq 2933 cpufreq: get returning known freq 2933 cpufreq: get returning known freq 2933 cpufreq: get returning known freq 2933 cpufreq: get returning known freq 2933 cpufreq: adding 8 relative settings cpufreq: adding abs setting 2933 at head cpufreq: expand set added rel setting 100% to 2933 level cpufreq: dup set considering derived setting 2566 cpufreq: removed last relative driver: p4tcc0 cpufreq: dup done, inserting new level 2566 after 2933 cpufreq: expand set added rel setting 87% to 2566 level cpufreq: dup set considering derived setting 2199 cpufreq: removed last relative driver: p4tcc0 cpufreq: dup done, inserting new level 2199 after 2566 cpufreq: expand set added rel setting 75% to 2199 level cpufreq: dup set considering derived setting 1833 cpufreq: removed last relative driver: p4tcc0 cpufreq: dup done, inserting new level 1833 after 2199 cpufreq: expand set added rel setting 62% to 1833 level cpufreq: dup set considering derived setting 1466 cpufreq: removed last relative driver: p4tcc0 cpufreq: dup done, inserting new level 1466 after 1833 cpufreq: expand set added rel setting 50% to 1466 level cpufreq: dup set considering derived setting 1099 ........ Hundreds of those lines, Keeps repeating, fast to slow to fast etc... > > > >> It shows that the freq is controlled well, goes down to 365 mhz but > > >> the tdp is not decreased, rather it increases. > >Yes you're only getting p4tcc throttling as Alexander points out. You'll >need to get est working to get power reduction from lower frequencies, >which likely won't correspond to these f/8 step throttling frequencies. > >As Jeremy suggested, here's how to turn throttling off, and something >like what you could expect with est working: >http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055666.html from link: I would recommend you to disable it by setting: hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 I get unknown oid on both. Not sure how to disable p4tcc here. What I have to work with. dev.p4tcc.0.%desc: CPU Frequency Thermal Control dev.p4tcc.0.%driver: p4tcc dev.p4tcc.0.%parent: cpu0 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.1.%desc: CPU Frequency Thermal Control dev.p4tcc.1.%driver: p4tcc dev.p4tcc.1.%parent: cpu1 dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 Tried variations of dev instead of hint, no go. going to c3 lowers it about a watt with powerd running to 43. c2 would be somewhere inbetween? %sysctl -a | grep lowest debug.cpufreq.lowest: 0 hw.acpi.cpu.cx_lowest: C1 dev.cpu.0.cx_lowest: C1 dev.cpu.1.cx_lowest: C1 % %sysctl -a | grep C1 hw.acpi.cpu.cx_lowest: C1 dev.cpu.0.cx_supported: C1/1 C2/1 C3/150 dev.cpu.0.cx_lowest: C1 dev.cpu.1.cx_supported: C1/1 C2/1 C3/150 dev.cpu.1.cx_lowest: C1 % %sysctl hw.acpi.cpu.cx_lowest=C2 hw.acpi.cpu.cx_lowest: C1 -> C2 42/43 watts now %sysctl dev.cpu.0.cx_lowest=C2 dev.cpu.0.cx_lowest: C2 -> C2 %sysctl dev.cpu.1.cx_lowest=C2 dev.cpu.1.cx_lowest: C2 -> C2 no other change with above 2 lines. %killall powerd It drops to 41 watts while still in C2 > > > >> If I disable eist, c1 and c3 helpers in bios, as per suggestion in > > >> mail archive, then it adds 1 watt to both figures. I was hoping to get > > >> this total tdp down to a very low amount, and it is but it should > > >> theoretically go lower with powerd, right? > >If powerd were actually reducing frequency (and voltage) via est it >certainly would. Finding out why est is failing to attach on your >hardware is the only likely path to success, try focusing on that and >ignoring side issues. Have you browsed freebsd-acpi archives re this? Sounds right, I did not find the est code yet to peruse it some. Otherwise I am out of clues on what to do. > > >> load 3%, current freq 365 MHz ( 7), wanted freq 365 MHz > > >> load 0%, current freq 365 MHz ( 7), wanted freq 365 MHz > > > > > >Your ACPI BIOS seems not reporting tables required to control EIST. So > > >powerd probably uses only thermal throttling, which is not really > > >effective for power saving on modern CPUs. You should check your BIOS > > >options or may be update BIOS. > > > > > >If you have no luck with EIST - try to use C-states if BIOS reports at > > >least them. It also can be quite effective. > > > > > >-- > > >Alexander Motin > > > > Thanks for the info, I did try to kick it to C3 and that helped poquito > > amount. Everything is enabled in bios that matters to this, that does help a > > little too but powerd actually raises tdp a little. See other recent reply > > for more info. > >Have you tried C2? Are you running the latest BIOS? And perhaps your >ACPI ASL may be amenable to repair, if Gigabyte ACPI is broken here? Changes to the asl are a bit more than I would want to get into. If I can find the est code then I might dig further.. Bios is most recent, has EIST, c1e and c2e I believe enabled. That seems to do the best all by itself. Maybe It does no good to beat a dead horse?? :-) I see an ITE IT8718F-S chip on board. mbmon does work somewhat but its code is way old and does not see the newer chip versions. some good docs with mbmon in usr/local/share/docs tho.. %mbmon -d -A Summary of Detection: * ISA monitor(s): ** Nat.Semi.Con. Chip LM78 found. ** Int.Tec.Exp. Chip IT8705F/IT8712F or SIS950 found vcore is 1.14 now but most of the rest are not correct readings. It is 1.28 without bios settings enabled. It never gets lower. Probably if I declock it below 2.93. 1.05 is what I was hoping to go down to or lower at 365mhz. %mbmon Temp.= 191.0, 0.0, 0.0; Rot.= 874, 3358, 2657 Vcore = 1.14, 1.92; Volt. = 3.31, 4.92, 1.09, -14.19, -6.12 Temp.= 191.0, 0.0, 0.0; Rot.= 874, 3358, 2657 Vcore = 1.15, 1.92; Volt. = 3.31, 4.92, 1.09, -14.19, -6.12 % %powerd -n adp %mbmon Temp.= 191.0, 0.0, 0.0; Rot.= 874, 3358, 2657 Vcore = 1.18, 1.92; Volt. = 3.31, 4.92, 1.22, -14.19, -6.12 Temp.= 191.0, 0.0, 0.0; Rot.= 874, 3358, 2657 Vcore = 1.14, 1.92; Volt. = 3.31, 4.92, 1.16, -14.19, -6.12 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. > >cheers, Ian Thanks to everyone that responded. John