Date: Sat, 27 Mar 2010 16:51:49 -0700 From: John Long <fbsd2@sstec.com> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: Alexander Motin <mav@freebsd.org>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, Ian Smith <smithi@nimnet.asn.au> Subject: Re: Powerd and est / eist functionality Message-ID: <5.2.1.1.2.20100327152415.0320bf28@mail.sstec.com> In-Reply-To: <20100326091447.GA91547@icarus.home.lan> References: <5.2.1.1.2.20100325235505.031e8338@mail.sstec.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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="00000000-0000-0000-0000-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. > >...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. John > >-- >| Jeremy Chadwick jdc@parodius.com | >| Parodius Networking http://www.parodius.com/ | >| UNIX Systems Administrator Mountain View, CA, USA | >| Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.2.1.1.2.20100327152415.0320bf28>