Date: Sat, 27 Mar 2010 18:53:21 -0700 From: John Long <fbsd2@sstec.com> To: Ian Smith <smithi@nimnet.asn.au>, Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: Alexander Motin <mav@freebsd.org>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: Powerd and est / eist functionality Message-ID: <5.2.1.1.2.20100327165629.032357b0@mail.sstec.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.2.1.1.2.20100327165629.032357b0>