Re: Powerd and est / eist functionality
At 05:42 PM 3/27/2010, Jeremy Chadwick wrote: On Sat, Mar 27, 2010 at 04:51:49PM -0700, John Long wrote: At 02:14 AM 3/26/2010, Jeremy Chadwick wrote: % dmesg | grep -i smbus pci0: serial bus, SMBus at device 31.3 (no driver attached) All this means is that there's a SMBus-class device sitting on the PCI bus which has no driver attached to it. Run pciconf -lvc and find the device in question, and the output relevant to it. no...@pci0:0:31:3: class=0x0c0500 card=0x50011458 chip=0x27da8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus put this in # Intel Core/Core2Duo CPU temperature monitoring driver device coretemp # SMBus support, needed for bsdhwmon device smbus device smb device ichsmb now get this ichs...@pci0:0:31:3:class=0x0c0500 card=0x50011458 chip=0x27da8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus %smbmsg -p Probing for devices on /dev/smb0: Device @0x10: w Does not look to be much there if I am doing this right.. Given the topic of discussion, I'd say your northbridge is Intel-based, which means you need the smb, smbus, and ichsmb drivers loaded. You can load these as kernel modules as well. When loading them, do not specify the trailing .ko. See the ichsmb(4) man page for some terse details. Even if you get a driver attached to the SMBus piece of the northbridge, like I said, there's no guarantee there's a H/W monitoring IC that's wired to the SMBus. As stated, I don't believe in probing slave addresses on the SMBus, so the slave address would have to come from Gigabyte, or... There's a program for Windows (9x/2K/XP/Vista) called SpeedFan which does do probing and can/does support SMBus. I have no idea if it works on Windows 7 or not: http://www.almico.com/speedfan.php If SpeedFan shows you all the data you expect/want, and indicates it's talking to a H/W IC over SMBus, then I could add support for your board to bsdhwmon (since your motherboard does provide acceptable SMBIOS tables for identification). I'd still need to know what slave address the chip had, and what exact model of H/W IC it was. SpeedFan might provide that. I have a feeling that my smbus is just not hooked up, nothing there.. speedfan looks cool tho. It would also help (me at least) if you could reboot your system, go into your BIOS and find whatever menu item is associated with Hardware Monitoring and write down all of the shown attributes and their values. What the BIOS shows is what should be accurate above all else. I can point you to numerous present-day motherboards that work just fine with cpufreq(4) and est under RELENG_8, and also work when using acpi_throttle. Specifically, Supermicro PDSMi+, X7SBA, and X7SBL-L2 boards. I'm sure there are many others. In all of these are Core2Duo or Core2Quad CPUs. An example from the X7SBA system, running powerd: It looks good, all working.. I should note that the device attachment error (error 6) is something I've seen on my PDSMi+ boards under RELENG_7 when EIST and C1 Enhanced Mode were disabled in the BIOS. FreeBSD would report that SpeedStep existed but that it wasn't able to attach. I *explicitly* disabled those features in the BIOS since I saw some bizarre process behaviour (calcru: runtime went backwards ... for pid X). Have you tried to measure the wall power with a kill-a-watt yet or can you? I am curious that things are actually working and tdp goes down when powerd is running vs not. About 20.00 - lowes, costco etc http://www.google.com/search?q=kill-a-watt very handy to check everything out. My system takes about 15 secs to lower freq to min and the power goes up a watt each 5 secs or so. Yes, it looks like it is working but the power meter tells the truth. John -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Powerd and est / eist functionality
On Sun, Mar 28, 2010 at 12:16:27AM -0700, John Long wrote: At 05:42 PM 3/27/2010, Jeremy Chadwick wrote: put this in # Intel Core/Core2Duo CPU temperature monitoring driver device coretemp coretemp(4) will get you the temperatures of each processor core, provided via the dev.cpu.X.temperature sysctls. %smbmsg -p Probing for devices on /dev/smb0: Device @0x10: w Does not look to be much there if I am doing this right.. smbmsg -p won't help here -- I've never seen it detect H/W ICs that sit on SMBus. In fact, on all my systems, it doesn't report anything exists on the slave address tied to the boards' Winbond chips. I have no idea what probe modus means (see smbmsg(8) man page) nor how the probe actually works behind the scenes. So, it's an ineffective way to get an answer to your dilemma. It would make more sense to run SpeedFan on Windows, see if it's able to find a chip via SMBus, and provide those details. Another alternative would be to try using lm-sensors on Linux, although I'm pretty sure lm-sensors prefers LPC/ISA mode (claiming it's more stable and more reliable -- whatever). I have no experience with this software, aside from occasionally having to dig through their spaghetti code to try and find details about chip quirks. There's a program for Windows (9x/2K/XP/Vista) called SpeedFan which does do probing and can/does support SMBus. I have no idea if it works on Windows 7 or not: http://www.almico.com/speedfan.php If SpeedFan shows you all the data you expect/want, and indicates it's talking to a H/W IC over SMBus, then I could add support for your board to bsdhwmon (since your motherboard does provide acceptable SMBIOS tables for identification). I'd still need to know what slave address the chip had, and what exact model of H/W IC it was. SpeedFan might provide that. I have a feeling that my smbus is just not hooked up, nothing there.. speedfan looks cool tho. I don't know what you mean by my smbus is just not hooked up. Your above 'device' additions to your kernel shows that FreeBSD is now able to talk to the SMBus interface on your northbridge. As stated, smbmsg isn't going to help determine what H/W IC is on your board (if any). I'll see if I can find a very high resolution photo of your motherboard and try to work out if any ASICs are used for H/W monitoring (these days such chips also often provide Super I/O support (floppy, LPT, COM, LPC/ISA, etc.)). I'll probably have to review the user manual. I'll report back once I do that. It would also help (me at least) if you could reboot your system, go into your BIOS and find whatever menu item is associated with Hardware Monitoring and write down all of the shown attributes and their values. What the BIOS shows is what should be accurate above all else. I can point you to numerous present-day motherboards that work just fine with cpufreq(4) and est under RELENG_8, and also work when using acpi_throttle. Specifically, Supermicro PDSMi+, X7SBA, and X7SBL-L2 boards. I'm sure there are many others. In all of these are Core2Duo or Core2Quad CPUs. An example from the X7SBA system, running powerd: It looks good, all working.. Okay, but that doesn't help me any. :-) Can you please write down all the H/W monitoring attributes + values shown in the BIOS and provide them here? I should note that the device attachment error (error 6) is something I've seen on my PDSMi+ boards under RELENG_7 when EIST and C1 Enhanced Mode were disabled in the BIOS. FreeBSD would report that SpeedStep existed but that it wasn't able to attach. I *explicitly* disabled those features in the BIOS since I saw some bizarre process behaviour (calcru: runtime went backwards ... for pid X). Have you tried to measure the wall power with a kill-a-watt yet or can you? I have a couple Kill-a-Watt devices, but I tend to not bother with them for tests of this nature since they don't provide enough granularity on the LCD (only 1 or 2 digits past the decimal point). I also find them to be finicky/unreliable -- for example, I hooked a residential home toaster up to a RackPDU (which provides amps and watts used via web + SNMP). Powering on the toaster showed an increase from 0.00 amps to 1.1 amps. Hooking the same toaster up to 2 separate Kill-a-Watt units returned the same result: 0.4 amps. I performed the same tests with a standard household fan (3-speed), and I saw similar readings (the Kill-a-Watt always appearing off by a pretty large amount). WRT all the systems I've applied cpufreq(4) + est + powerd to: they're all production. I'm not willing to power them down, go to the co-lo, hook up a Kill-a-Watt device, power them on, wait around for 30 minutes, etc.. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for
Re: Powerd and est / eist functionality
On Sun, Mar 28, 2010 at 12:42:02PM -0700, Jeremy Chadwick wrote: I'll see if I can find a very high resolution photo of your motherboard and try to work out if any ASICs are used for H/W monitoring (these days such chips also often provide Super I/O support (floppy, LPT, COM, LPC/ISA, etc.)). I'll probably have to review the user manual. I'll report back once I do that. Success -- the Gigabyte GA-G41M-ES2L board uses an ITE IT8718 Super I/O chip, which also drives H/W monitoring support. Verified both visually and in the user manual. The official datasheets for the IT8718 are here: http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3ID=5,68 Regardless of chip subrevision (J vs. K), neither supports SMBus; the chips appear to be entirely LPC/ISA-based. mbmon could be extended/enhanced to support this chip (mbmon -I would be required), but you'd still need to know what I/O ports are that Gigabyte tie to the chip. That's where Linux lm-sensors comes into play. Based on some Google results, the base I/O port is probably 0x290 (I'm assuming 0x290 = read, 0x291 = write) -- but I'm basing that on some ambiguous output here: http://lists.lm-sensors.org/pipermail/lm-sensors/2009-January/025222.html http://www.lm-sensors.org/wiki/Configurations/Gigabyte There's also this, which is pretty disheartening: http://lists.lm-sensors.org/pipermail/lm-sensors/2006-August/017423.html The IT8718F also features VID inputs (up to 8 pins) but the value is stored in the Super-I/O configuration space. Due to technical limitations, this value can currently only be read once at initialization time, so the driver won't notice and report changes in the VID value. The two upper VID bits share their pins with voltage inputs (in5 and in6) so you can't have both on a given board. If someone feels like contacting the mbmon author to get this added, be my guest. Or if someone feels like adding it to mbmon, that's cool too. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Powerd and est / eist functionality
At 03:16 AM 3/25/2010, Torfinn Ingolfsen wrote: On Wed, 24 Mar 2010 18:04:51 -0700 John Long fb...@sstec.com wrote: I want to thank you very much for all the info you have provided. It has clued me into a much better understanding and I see that it is a big un-standard thing to monitor these functions. It seems that things are FYI: for (some) Asus boards thererb is als acpi_aiboost(4). I wish I had known that b4. Thanks -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Powerd and est / eist functionality
At 02:14 AM 3/26/2010, Jeremy Chadwick wrote: On Fri, Mar 26, 2010 at 01:20:19AM -0700, John Long wrote: 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. These are /boot/loader.conf tunables, not sysctl. I'm pretty sure I stated that in my previous mail...? Drats, you are right. too late at night.. did not give me anything positive anyway. 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 Ignore all of the above values -- mbmon doesn't work properly with your board, or that sub-revision of IT chip. It's that simple. Re-read the rant I sent you for explanation; I already covered all the bases. :-) I disagree about the mbmon docs -- they're more like chaotic brain dumps or scribbled notes than actual coherent, well-written instructions or details. Agreed, but they were something vs not much and I was grasping :-) That said, I have utmost respect for SHIMIZU Yoshifumi and his efforts/work. I'm willing to make an exception here. If you can get the following information from the motherboard manufacturer, I'd be willing to add support for your board to bsdhwmon. What I need: 1) The exact H/W monitoring IC they use (not what mbmon says, and not what's silkscreened on the chip), That would be a bit impossible for me, what is on the chip is all I can provide. 2) If the H/W monitoring IC is tied in to SMBus, hellava question too, Tell me and we would both know :-) 3) What the SMBus slave address is they chose for the H/W IC % dmesg | grep -i smbus pci0: serial bus, SMBus at device 31.3 (no driver attached) I am pretty sure I would get a deer in the headlights response from gigabyte over this question.. 4) Output of kenv | grep smbios from your system. kenv | grep smbios smbios.bios.reldate=11/04/2009 smbios.bios.vendor=Award Software International, Inc. smbios.bios.version=F6 smbios.chassis.maker=Gigabyte Technology Co., Ltd. smbios.chassis.serial= smbios.chassis.tag= smbios.chassis.version= smbios.memory.enabled=1048576 smbios.planar.maker=Gigabyte Technology Co., Ltd. smbios.planar.product=G41M-ES2L smbios.planar.serial= smbios.planar.version=x.x smbios.socket.enabled=1 smbios.socket.populated=1 smbios.system.maker=Gigabyte Technology Co., Ltd. smbios.system.product=G41M-ES2L smbios.system.serial= smbios.system.uuid=----6cf049635a47 smbios.system.version= smbios.version=2.4 1 out of 4 is not too bad :-) Assuming all of the above meets necessary criteria, I can probably add support for this board to bsdhwmon. I have only slight qualms/concerns adding consumer boards to bsdhwmon, but the big kicker is that the board **must** have an actual H/W monitoring IC tied/wired to SMBus. I *will not* use the old LPC/ISA (/dev/io) infrastructure. I understand, there are just too many possible different implementations and chips being used. Getting Vcore from both healthd and mbmon, being about the same and that being the main concern for my discovery into functionality has me satiated. Getting the rest of the sensors would be great but certainly would not be worth any effort from you or anyone for just this one of hundreds of mbds. I do appreciate the offer tho. I should of bought Asus in the first place. I always have for past 12 years but my selection dwindled about 3 weeks ago when Frys dropped the asus p5qpl-am. That was the only non realtek ether g41 mbd I could find. I took a chance that the re8111 (gigabyte and most others) drivers would work as well and it looks like they do. The only remaining viable asus mbd, to me, is the p5g41-m lx2/gm but a search on asus's site and it is not to be found therefore that would be a nono for me. There are just too many different mbds out there, the manufs have just gone hog wild. 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.
Re: Powerd and est / eist functionality
On Sat, Mar 27, 2010 at 04:51:49PM -0700, John Long wrote:
At 02:14 AM 3/26/2010, Jeremy Chadwick wrote:
I'm willing to make an exception here. If you can get the following
information from the motherboard manufacturer, I'd be willing to add
support for your board to bsdhwmon. What I need:
{snip}
3) What the SMBus slave address is they chose for the H/W IC
% dmesg | grep -i smbus
pci0: serial bus, SMBus at device 31.3 (no driver attached)
All this means is that there's a SMBus-class device sitting on the PCI
bus which has no driver attached to it. Run pciconf -lvc and find the
device in question, and the output relevant to it.
Given the topic of discussion, I'd say your northbridge is Intel-based,
which means you need the smb, smbus, and ichsmb drivers loaded. You can
load these as kernel modules as well. When loading them, do not specify
the trailing .ko. See the ichsmb(4) man page for some terse details.
Even if you get a driver attached to the SMBus piece of the northbridge,
like I said, there's no guarantee there's a H/W monitoring IC that's
wired to the SMBus. As stated, I don't believe in probing slave
addresses on the SMBus, so the slave address would have to come from
Gigabyte, or...
There's a program for Windows (9x/2K/XP/Vista) called SpeedFan which
does do probing and can/does support SMBus. I have no idea if it works
on Windows 7 or not:
http://www.almico.com/speedfan.php
If SpeedFan shows you all the data you expect/want, and indicates it's
talking to a H/W IC over SMBus, then I could add support for your board
to bsdhwmon (since your motherboard does provide acceptable SMBIOS
tables for identification). I'd still need to know what slave address
the chip had, and what exact model of H/W IC it was. SpeedFan might
provide that.
It would also help (me at least) if you could reboot your system, go
into your BIOS and find whatever menu item is associated with Hardware
Monitoring and write down all of the shown attributes and their values.
What the BIOS shows is what should be accurate above all else.
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).
This repeated clue got me to the next step and I thank you for that.
The key, as I see it, is to get est working either by getting the
msr tables updated somehow or getting the acpi working better so est
could fall back on it therefore powerd would have a better set of
signals to use rather than thermal. Like I have mentioned elsewhere,
it looks like est has not really been updated nor worked on much for
about 5 years and is missing the proper tables for the mbds since.
That is a big and near impossible job unless it can be modded to a
sort of wildcard detection if there is some commonality to newer
mbds.
I can point you to numerous present-day motherboards that work just fine
with cpufreq(4) and est under RELENG_8, and also work when using
acpi_throttle. Specifically, Supermicro PDSMi+, X7SBA, and X7SBL-L2
boards. I'm sure there are many others. In all of these are Core2Duo
or Core2Quad CPUs. An example from the X7SBA system, running powerd:
CPU1 Temperature 41 C
System Temperature 36 C
FAN10 RPM
FAN20 RPM
FAN30 RPM
FAN4 1988 RPM
FAN5 1532 RPM
FAN6 1809 RPM
VcoreA 1.220 V
MCH Core1.514 V
-12V -11.904 V
V_DIMM 1.712 V
+3.3V 3.360 V
+12V 12.000 V
5Vsb5.118 V
5VDD5.022 V
P_VTT 1.140 V
Vbat3.312 V
And relevant sysctls:
debug.cpufreq.verbose: 0
debug.cpufreq.lowest: 0
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
dev.cpufreq.1.%driver: cpufreq
dev.cpufreq.1.%parent: cpu1
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.temperature: 41.0C
dev.cpu.0.freq: 2000
dev.cpu.0.freq_levels: 3000/35000 2667/28000 2333/22000 2000/16000
dev.cpu.0.cx_supported: C1/0 C2/85
dev.cpu.0.cx_lowest: C2
dev.cpu.0.cx_usage: 49.99% 50.00% last 286us
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.temperature: 41.0C
dev.cpu.1.cx_supported: C1/0 C2/85
dev.cpu.1.cx_lowest: C2
dev.cpu.1.cx_usage: 49.99% 50.00% last 286us
dev.est.0.%desc: Enhanced SpeedStep Frequency Control
dev.est.0.%driver: est
dev.est.0.%parent: cpu0
dev.est.0.freq_settings: 3000/35000 2667/28000 2333/22000 2000/16000
dev.est.1.%desc: Enhanced SpeedStep
Re: Powerd and est / eist functionality
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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Powerd and est / eist functionality
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 1 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:
Re: Powerd and est / eist functionality
John Long wrote: 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? As I can see, your ACPI reports C3 state support. You may try it also. Here is my notes about power and C3 also: http://wiki.freebsd.org/TuningPowerConsumption -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Powerd and est / eist functionality
On Fri, Mar 26, 2010 at 01:20:19AM -0700, John Long wrote: 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. These are /boot/loader.conf tunables, not sysctl. I'm pretty sure I stated that in my previous mail...? 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 Ignore all of the above values -- mbmon doesn't work properly with your board, or that sub-revision of IT chip. It's that simple. Re-read the rant I sent you for explanation; I already covered all the bases. :-) I disagree about the mbmon docs -- they're more like chaotic brain dumps or scribbled notes than actual coherent, well-written instructions or details. That said, I have utmost respect for SHIMIZU Yoshifumi and his efforts/work. I'm willing to make an exception here. If you can get the following information from the motherboard manufacturer, I'd be willing to add support for your board to bsdhwmon. What I need: 1) The exact H/W monitoring IC they use (not what mbmon says, and not what's silkscreened on the chip), 2) If the H/W monitoring IC is tied in to SMBus, 3) What the SMBus slave address is they chose for the H/W IC 4) Output of kenv | grep smbios from your system. Assuming all of the above meets necessary criteria, I can probably add support for this board to bsdhwmon. I have only slight qualms/concerns adding consumer boards to bsdhwmon, but the big kicker is that the board **must** have an actual H/W monitoring IC tied/wired to SMBus. I *will not* use the old LPC/ISA (/dev/io) infrastructure. 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). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Powerd and est / eist functionality
At 01:31 AM 3/26/2010, Alexander Motin wrote:
John Long wrote:
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?
As I can see, your ACPI reports C3 state support. You may try it also.
Here is my notes about power and C3 also:
http://wiki.freebsd.org/TuningPowerConsumption
Alexander Motin
Hi, you have achieved good results with your laptop tuning, 50% power
reduction.
I tried the disable thing and got what I thought would happen.
hint.p4tcc.0.disabled=1
hint.acpi_throttle.0.disabled=1
Since est is not working on this system then it falls back to p4tcc and
throttle but if they are disabled then powerd chokes with lookup freq: no
such file or directory and does not run.
I did locate est.c under cpufreq dir. It looks to be from 2004/5 era and
alas the cpu lookups in there are most all from that time frame also. I
find this bit of code:
/*
* Probe for supported CPU settings. First, check our static table of
* settings. If no match, try using the ones offered by acpi_perf
* (i.e., _PSS). We use ACPI second because some systems (IBM R/T40
* series) export both legacy SMM IO-based access and direct MSR access
* but the direct access specifies invalid values for _PSS.
*/
static int
est_get_info(device_t dev)
{
struct est_softc *sc;
uint64_t msr;
int error;
sc = device_get_softc(dev);
msr = rdmsr(MSR_PERF_STATUS);
error = est_table_info(dev, msr, sc-freq_list);
if (error)
error = est_acpi_info(dev, sc-freq_list);
if (error)
error = est_msr_info(dev, msr, sc-freq_list);
if (error) {
printf(
est: CPU supports Enhanced Speedstep, but is not recognized.\n
est: cpu_vendor %s, msr %0jx\n, cpu_vendor, msr);
return (ENXIO);
}
return (0);
}
Therein looks to be the problem, the msr table/freq_list lookup is just way
out of date and fails to load est and therefore the fallback to p4tcc for
powerd which is useless for reduction. I need to get est running so that it
handles the P-states which include the voltage reduction. There are a
couple other places where it tests and sets flags that may be relevant but
it is a little bit more work and a little over my head than I was looking
for. Maybe ACPI is just not giving enough info and the asl can be modified
but I do not know enough about it or much of any of this.. There is a whole
box of worms in acpica dir. I looked thru acpi_perf.c but the rabbit trail
looks a bit daunting. There are briar patches throughout.
Maybe Colin Percival or Nate Lawson can shed some light on this and if it
is reasonable to do an update for that bit of code/table. If there were a
prog that could invoke est.c and have it spit out the factors it sees for a
clue as to just what might be needed to get it loaded, that would be helpful.
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 6160b2506000b25
is meaningless to me :-(
I do realize that there have been hundreds of cpus and factors since that
time, maybe a wildcard lookup of some sort would suffice. To just get this
thing loaded because the rest of the code looks clever and good. Also, if
some discovery here helps the project and saves a few watts times thousands
of us then it might be worth pursuing but if the general consensus is not
worth the trouble then I understand.
John
btw: I had tried C3 earlier and C2 also, they both save about 1 watt max
and C3 is quite a dramatic thing to do considering the crucial parts of the
system it shuts down. For a laptop that would be okay but this is going to
be a relatively busy server running dns, apache, nat etc. I do not think it
will have much time to sleep but with the speed of a c2d it will not been
too busy either, always just a few percent. Therein lies my desire, to get
the voltage down when the freq is low and still allow demand speed to be
there if needed.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Powerd and est / eist functionality
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?
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. Some of
the more gritty documentation may be found browsing with something like:
% less /sys/{sys,kern,amd64/include}/*cpu*.[ch]
cheers, Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Powerd and est / eist functionality
On Wed, 24 Mar 2010 18:04:51 -0700 John Long fb...@sstec.com wrote: I want to thank you very much for all the info you have provided. It has clued me into a much better understanding and I see that it is a big un-standard thing to monitor these functions. It seems that things are FYI: for (some) Asus boards thererb is als acpi_aiboost(4). -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Powerd and est / eist functionality
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? Turning on debug.cpufreq.verbose and hw.acpi.verbose may add clues? 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 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? 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? cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Powerd and est / eist functionality
At 07:55 PM 3/22/2010, Nenhum_de_Nos wrote: On Mon, March 22, 2010 19:57, John Long wrote: dmesg shows cpu0: ACPI CPU on acpi0 est0: Enhanced SpeedStep Frequency Control on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6160b2506000b25 device_attach: est0 attach returned 6 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6160b2506000b25 device_attach: est1 attach returned 6 p4tcc1: CPU Frequency Thermal Control on cpu1 I get similar output on 8-STABLE and C2Q 9400/9450. wasn't it supposed to attach ok ? matheus I am not sure just what is the best way for all this to work. I do not know what a return of 6 means (not recognized?) or how to fix it. I can find no similar mention anywhere of the fact that power is increased and not lowered by the use of powerd or similar and thought that would provoke some hints and more discussion because it is intriguing and it self negates its own purpose and functionality. I am trying to ascertain the viability of this motherboard w/ regards to getting the power function working proper and am constrained by the lack of monitoring tools vs what cupid.com has for win with hwmonitor and cpuz (they have a dev kit also). Would another brand/model of mb work better? I know that most all are lacking in acpi function in diff ways. Maybe I am squeezing water out of a rock, that the cpu is at its min or 6 watts now, but I just do not know. Btw: Intel is blowing out all 775 type chips. Today is about the last day. They want everyone on I3/I5 etc but they are not as functional re low tdp as 775 chips. Just because you lower the freq by stretching the clock or actually lowering the freq does not result in a lower TDP. I do not think that the multiplier being lowered in this case. What appears to be happening is that the cpu gets busier and that increases the tdp over not using it at all making it less than useless in my case. I can find very little comprehensive info on how the eist/est//p4tcc/powerd thing is supposed to work. Reading source of powerd is not helping. Logically, if the voltage is lowered then the power is going to be lower. Is the voltage a function of the load automatically controlled by hardware and/or the bios or is it supposed to be an artifact of the freq being lowered by something like powerd? I believe the former for the latter is not working. I now have everything relevant in the bios enabled. est appears to be not working but what would happen if it were working? Is that the key to lowering the TDP when the freq is lowered? Then what is required for it to work? Where would I find the source in the tree? p4tcc appears that it is a failsafe for thermal runaway and since my temp is 26 - 30 or so all the time then it would be of no use because there is too little differential. I csupd to stable and rebuilt and there is no difference w/ this prob. I did see that I went from SATA150 (it should be SATA300) to udma100 sata but that is for another thread. I changed hw.acpi.cpu.cx_lowest=C1 to C3 and that saved me about 1.5 watts w/ powerd but it is still a watt higher than without powerd running at all. Does anyone know of anything else I can try or is this the best it can get? John seemingly relevant sysctls: debug.acpi.suspend_bounce: 0 debug.acpi.reset_clock: 1 debug.acpi.do_powerstate: 1 debug.acpi.acpi_ca_version: 20100121 debug.acpi.ec.timeout: 750 debug.acpi.ec.polled: 0 debug.acpi.ec.burst: 0 debug.acpi.batt.batt_sleep_ms: 0 debug.acpi.resume_beep: 0 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 0 hw.pcic.pd6722_vsense: 1 hw.pcic.intr_mask: 57016 hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: NONE hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 dev.acpi.0.%desc: GBT GBTUACPI dev.acpi.0.%driver: acpi dev.acpi.0.%parent: nexus0 dev.acpi_sysresource.0.%desc: System Resource dev.acpi_sysresource.0.%driver: acpi_sysresource dev.acpi_sysresource.0.%location: handle=\_SB_.PCI0.PX40.SYSR dev.acpi_sysresource.0.%pnpinfo: _HID=PNP0C02 _UID=1 dev.acpi_sysresource.0.%parent: acpi0 dev.acpi_sysresource.1.%desc: System Resource dev.acpi_sysresource.1.%driver: acpi_sysresource dev.acpi_sysresource.1.%location: handle=\_SB_.PCI0.PX40.PMIO dev.acpi_sysresource.1.%pnpinfo: _HID=PNP0C02 _UID=2 dev.acpi_sysresource.1.%parent: acpi0 dev.acpi_sysresource.2.%desc: System Resource dev.acpi_sysresource.2.%driver: acpi_sysresource dev.acpi_sysresource.2.%location: handle=\_SB_.PCI0.EXPL dev.acpi_sysresource.2.%pnpinfo:
Re: Powerd and est / eist functionality
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. It shows that the freq is controlled well, goes down to 365 mhz but the tdp is not decreased, rather it increases. 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? The bios reports 1.268V and 26C temp. I was hoping that the voltage would go down to .85 or so when powerd lowered the freq to 365 etc. Healthd does not seem to know what monitoring chip it is and I have no idea unless I install xp (ugh) and run something from cpuid.com on it. What is a good/better/best monitoring program, mbmon and bsdhwmon are untried for they are not current I see. Or what do I do from here to fix this problem? thx, John dmesg shows cpu0: ACPI CPU on acpi0 est0: Enhanced SpeedStep Frequency Control on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6160b2506000b25 device_attach: est0 attach returned 6 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6160b2506000b25 device_attach: est1 attach returned 6 p4tcc1: CPU Frequency Thermal Control on cpu1 powerd -v powerd: unable to determine AC line status load 0%, current freq 2926 MHz ( 0), wanted freq 2834 MHz load 0%, current freq 2926 MHz ( 0), wanted freq 2745 MHz ... 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. Thanks, John ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Powerd and est / eist functionality
On Wed, Mar 24, 2010 at 01:37:06PM -0700, John Long wrote: I am trying to ascertain the viability of this motherboard w/ regards to getting the power function working proper and am constrained by the lack of monitoring tools vs what cupid.com has for win with hwmonitor and cpuz (they have a dev kit also). Would another brand/model of mb work better? I know that most all are lacking in acpi function in diff ways. Maybe I am squeezing water out of a rock, that the cpu is at its min or 6 watts now, but I just do not know. You're placing too many eggs in one basket. Hardware monitoring is a separate beast, and one you won't find good support for on FreeBSD. By hardware monitoring I'm talking about thermals off the mainboard, fan RPMs, CPU temperature (not on-die temps), and voltages. Let's talk about those first, as they're something I'm familiar with. - These data sources are only available if the motherboard manufacturer added a H/W monitoring I/C to their mainboard. Consumer mainboards are spotty as far as offering this capability. - Each mainboard is different. Each mainboard model, or even subrevision, can use a completely different H/W monitoring chip. To make matters more complex, there are multiple models of H/W monitoring ICs, and even multiple revision/versions of the same model that behave completely different than their predecessor(s). - How this chip is implemented on the mainboard is up to the manufacturer. Some chips only exist on the LPC bus (think ISA I/O ports). Some chips support SMBus. The mainboard has to be engineered so that the pins on the H/W IC tie in to the LPC or SMBus bus(ses). You don't know which is available/used unless the manufacturer states such in their User Manual. - In the case of LPC, the exact I/O ports must be provided by the board manufacturer. In the case of SMBus, the slave address must be provided by the board manufacturer. **YOU CANNOT GUESS THESE** despite Linux's lm-sensors project having folks think otherwise. Guessing (probing) is very high risk, and involves submitting reads to a select set of LPC I/O ports (which could be used for other things/devices), or to a select SMBus slave address. Some registers do things to the system (or associated chips) on read operations; bits can get reset. I've seen this happen in the case of one Winbond chip where an incorrect CRxx read resulted in the chips' watchdog firing an NMI. - Knowing the exact model and subrevision of H/W IC is important, since programmer of the monitoring software has to know what all the register offsets are, how to decode the data, etc.. There is no standard, and there are multiple manufacturers of such devices (Nuvoton/Winbond, National Semiconductor, ON Semiconductor/Analog Devices, SMSC, TI, and some others. For a while companies like AMD, nVidia, Intel, Broadcom, ALi, and VIA were making their own chips as well). - In the case of SMBus, the operating system must have an SMBus driver for the system chipset (not H/W chip). For example, Intel systems often use ichsmb(4), AMD systems use amdsmb(4), and so on. Without a driver it's not feasible/possible for userland applications to talk to a device connected to SMBus. For sake of example, there's no SMBus driver on FreeBSD for ServerWorks chipsets. Getting all of this data out of the mainboard manufacturer is like pulling teeth, especially in the case of consumer boards. Server board manufacturers (Supermicro, Tyan, Intel, etc.) often disclose this information to those who request it via Technical Support. But if you were to mail, say, Asus for this information, it'd likely go in one ear and out the other. All that (negativity) said: the closest thing you'll find on FreeBSD to interface with these chips is ports/sysutils/mbmon, ports/sysutils/healthd, or ports/sysutils/bsdhwmon. mbmon supports very old mainboards which utilise LPC (it's SMBus support is broken/shoddy). It also tries auto-probing, often gets it wrong, and spits out readings which are incorrect/off the charts. Sometimes it gets things wrong and spits out values that look real but aren't. healthd is basically mbmon with some minor changes to the core but major changes to the surrounding user interface. bsdhwmon is intended for servers only and only speaks to devices using SMBus, of which I'm the author. Are we having fun yet? Now back to the bigger picture... CPU temperature (assuming you have a newer AMD or Intel CPU) is available via the coretemp(4) driver, and active CPU clock frequency is available via the cpufreq(4) drivers and their subsets. There is also some very archaic (IMHO) support for temperature monitoring via ACPI, but I believe that's mainly intended for laptops. With regards to ACPI, you're purely limited by what the mainboard/BIOS implementer does; many consumer motherboard vendors have absolutely no idea what to do with a technical support request asking they fix/improve their ACPI tables. For coretemp(4), you'll find
Re: Powerd and est / eist functionality
At 02:36 PM 3/24/2010, Jeremy Chadwick wrote: On Wed, Mar 24, 2010 at 01:37:06PM -0700, John Long wrote: I am trying to ascertain the viability of this motherboard w/ regards to getting the power function working proper and am constrained by the lack of monitoring tools vs what cupid.com has for win with hwmonitor and cpuz (they have a dev kit also). Would another brand/model of mb work better? I know that most all are lacking in acpi function in diff ways. Maybe I am squeezing water out of a rock, that the cpu is at its min or 6 watts now, but I just do not know. You're placing too many eggs in one basket. Hardware monitoring is a separate beast, and one you won't find good support for on FreeBSD. By hardware monitoring I'm talking about thermals off the mainboard, fan RPMs, CPU temperature (not on-die temps), and voltages. Let's talk about those first, as they're something I'm familiar with. - These data sources are only available if the motherboard manufacturer added a H/W monitoring I/C to their mainboard. Consumer mainboards are spotty as far as offering this capability. - Each mainboard is different. Each mainboard model, or even subrevision, can use a completely different H/W monitoring chip. To make matters more complex, there are multiple models of H/W monitoring ICs, and even multiple revision/versions of the same model that behave completely different than their predecessor(s). - How this chip is implemented on the mainboard is up to the manufacturer. Some chips only exist on the LPC bus (think ISA I/O ports). Some chips support SMBus. The mainboard has to be engineered so that the pins on the H/W IC tie in to the LPC or SMBus bus(ses). You don't know which is available/used unless the manufacturer states such in their User Manual. - In the case of LPC, the exact I/O ports must be provided by the board manufacturer. In the case of SMBus, the slave address must be provided by the board manufacturer. **YOU CANNOT GUESS THESE** despite Linux's lm-sensors project having folks think otherwise. Guessing (probing) is very high risk, and involves submitting reads to a select set of LPC I/O ports (which could be used for other things/devices), or to a select SMBus slave address. Some registers do things to the system (or associated chips) on read operations; bits can get reset. I've seen this happen in the case of one Winbond chip where an incorrect CRxx read resulted in the chips' watchdog firing an NMI. - Knowing the exact model and subrevision of H/W IC is important, since programmer of the monitoring software has to know what all the register offsets are, how to decode the data, etc.. There is no standard, and there are multiple manufacturers of such devices (Nuvoton/Winbond, National Semiconductor, ON Semiconductor/Analog Devices, SMSC, TI, and some others. For a while companies like AMD, nVidia, Intel, Broadcom, ALi, and VIA were making their own chips as well). - In the case of SMBus, the operating system must have an SMBus driver for the system chipset (not H/W chip). For example, Intel systems often use ichsmb(4), AMD systems use amdsmb(4), and so on. Without a driver it's not feasible/possible for userland applications to talk to a device connected to SMBus. For sake of example, there's no SMBus driver on FreeBSD for ServerWorks chipsets. Getting all of this data out of the mainboard manufacturer is like pulling teeth, especially in the case of consumer boards. Server board manufacturers (Supermicro, Tyan, Intel, etc.) often disclose this information to those who request it via Technical Support. But if you were to mail, say, Asus for this information, it'd likely go in one ear and out the other. All that (negativity) said: the closest thing you'll find on FreeBSD to interface with these chips is ports/sysutils/mbmon, ports/sysutils/healthd, or ports/sysutils/bsdhwmon. mbmon supports very old mainboards which utilise LPC (it's SMBus support is broken/shoddy). It also tries auto-probing, often gets it wrong, and spits out readings which are incorrect/off the charts. Sometimes it gets things wrong and spits out values that look real but aren't. healthd is basically mbmon with some minor changes to the core but major changes to the surrounding user interface. bsdhwmon is intended for servers only and only speaks to devices using SMBus, of which I'm the author. Are we having fun yet? Now back to the bigger picture... CPU temperature (assuming you have a newer AMD or Intel CPU) is available via the coretemp(4) driver, and active CPU clock frequency is available via the cpufreq(4) drivers and their subsets. There is also some very archaic (IMHO) support for temperature monitoring via ACPI, but I believe that's mainly intended for laptops. With regards to ACPI, you're purely limited by what the mainboard/BIOS implementer does; many consumer motherboard vendors have absolutely no idea what to do with a technical support request asking they fix/improve
Re: Powerd and est / eist functionality
On Wed, Mar 24, 2010 at 06:04:51PM -0700 I heard the voice of John Long, and lo! it spake thus: The i3/i5/i7 chips don't appear to offer ECC framework on their memory controllers (which are now on-die as I'm sure you know), which is why I plan to stay away from them for servers. I agree with your thoughts however I believe one can still use the I-series in a p55 board and get the ECC working Not the case. To use ECC, the memory controller has to support it. Nehalem moved the memory controller on-die, and on the non-Xeons, it doesn't have ECC capability. You'd have to go Xeon, use prior chips (with the memory controller on the motherboard) with careful motherboard selection, or use AMD (where all the chips have ECC in the IMC, though you still need a little care to be sure your motherboard doesn't sabotage it). -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Powerd and est / eist functionality
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. It shows that the freq is controlled well, goes down to 365 mhz but the tdp is not decreased, rather it increases. 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? The bios reports 1.268V and 26C temp. I was hoping that the voltage would go down to .85 or so when powerd lowered the freq to 365 etc. Healthd does not seem to know what monitoring chip it is and I have no idea unless I install xp (ugh) and run something from cpuid.com on it. What is a good/better/best monitoring program, mbmon and bsdhwmon are untried for they are not current I see. Or what do I do from here to fix this problem? thx, John dmesg shows cpu0: ACPI CPU on acpi0 est0: Enhanced SpeedStep Frequency Control on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6160b2506000b25 device_attach: est0 attach returned 6 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6160b2506000b25 device_attach: est1 attach returned 6 p4tcc1: CPU Frequency Thermal Control on cpu1 powerd -v powerd: unable to determine AC line status load 0%, current freq 2926 MHz ( 0), wanted freq 2834 MHz load 0%, current freq 2926 MHz ( 0), wanted freq 2745 MHz ... 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Powerd and est / eist functionality
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. It shows that the freq is controlled well, goes down to 365 mhz but the tdp is not decreased, rather it increases. 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? The bios reports 1.268V and 26C temp. I was hoping that the voltage would go down to .85 or so when powerd lowered the freq to 365 etc. Healthd does not seem to know what monitoring chip it is and I have no idea unless I install xp (ugh) and run something from cpuid.com on it. What is a good/better/best monitoring program, mbmon and bsdhwmon are untried for they are not current I see. Or what do I do from here to fix this problem? thx, John dmesg shows cpu0: ACPI CPU on acpi0 est0: Enhanced SpeedStep Frequency Control on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6160b2506000b25 device_attach: est0 attach returned 6 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6160b2506000b25 device_attach: est1 attach returned 6 p4tcc1: CPU Frequency Thermal Control on cpu1 powerd -v powerd: unable to determine AC line status load 0%, current freq 2926 MHz ( 0), wanted freq 2834 MHz load 0%, current freq 2926 MHz ( 0), wanted freq 2745 MHz ... load 3%, current freq 365 MHz ( 7), wanted freq 365 MHz load 0%, current freq 365 MHz ( 7), wanted freq 365 MHz healthd -d Unknown Vendor: ID = Temp.= 191.0, 159.0, 159.0; Rot.= 874, 3358, 2657 Vcore = 1.25, 1.92; Volt. = 3.31, 4.92, 1.16, -14.16, -6.12 Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz (2926.08-MHz K8-class CPU) Origin = GenuineIntel Id = 0x1067a Stepping = 10 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,P GE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS, HTT,TM,PBE Features2=0x408e3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR ,PDCM,SSE4.1,XSAVE AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 1073741824 (1024 MB) avail memory = 983613440 (938 MB) ACPI APIC Table: GBTGBTUACPI FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: GBT GBTUACPI on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 3dbe (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0xe400-0xe407 mem 0xe300-0xe33f,0xd000-0xdfff irq 16 at device 2.0 on pci0 pci0: multimedia, HDA at device 27.0 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge irq 17 at device 28.1 on pci0 pci2: ACPI PCI bus on pcib2 re0: RealTek 8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP PCIe Gigabit Ethernet port 0xc000-0xc0ff mem 0xe341000 0-0xe3410fff,0xe340-0xe340 irq 17 at device 0.0 on pci2 re0: Using 1 MSI messages re0: Chip rev. 0x3c00 re0: MAC rev. 0x0040 miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211B media interface PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
Re: Powerd and est / eist functionality
On Mon, March 22, 2010 19:57, John Long wrote: dmesg shows cpu0: ACPI CPU on acpi0 est0: Enhanced SpeedStep Frequency Control on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6160b2506000b25 device_attach: est0 attach returned 6 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6160b2506000b25 device_attach: est1 attach returned 6 p4tcc1: CPU Frequency Thermal Control on cpu1 I get similar output on 8-STABLE and C2Q 9400/9450. wasn't it supposed to attach ok ? matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
