Date: Thu, 11 Aug 2005 07:52:58 -0700 From: "Kevin Oberman" <oberman@es.net> To: Nate Lawson <nate@root.org> Cc: acpi@FreeBSD.org Subject: Re: 5-STABLE cpufreq hotter than est from ports Message-ID: <20050811145258.10F615D08@ptavv.es.net> In-Reply-To: Your message of "Wed, 10 Aug 2005 23:13:11 PDT." <42FAEC77.3020003@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Wed, 10 Aug 2005 23:13:11 -0700 > From: Nate Lawson <nate@root.org> > > Kevin Oberman wrote: > >>Date: Tue, 9 Aug 2005 11:35:29 +0200 > >>From: Bruno Ducrot <ducrot@poupinou.org> > >>Sender: owner-freebsd-stable@freebsd.org > >> > >>On Tue, Aug 02, 2005 at 12:22:02AM +0200, Tijl Coosemans wrote: > >> > >>>A couple days ago I updated my system and was excited to see cpufreq > >>>and powerd in 5-stable. Since then however I noticed that my laptop > >>>temperature is about 5°C higher than with est and estctrl. I found that > >>>cpufreq when setting 200MHz for example set the absolute frequency to > >>>1600MHz (max for this laptop) and the relative frequency (p4tcc) to > >>>12.5% instead of using a more power conserving setting like 800MHz/25%. > >>> > >>>The problem is that cpufreq_expand_set() (sys/kern/kern_cpu.c) > >>>traverses freq levels from high to low when adding relative levels and > >>>skips duplicates. When it wants to add 800MHz/25% it sees this setting > >>>as a duplicate of 1600MHz/12.5% it has found before. This can be fixed > >>>by letting cpufreq_expand_set() traverse freq levels in reverse order > >>>(and still skipping duplicates). Then each frequency level has the > >>>lowest possible absolute setting. This is a one line change in > >>>sys/kern/kern_cpu.c (line 653). > >> > >>It's a well known bug. Someday I think I will have enough time to fix > >>that one if Nate don't bite me. > > > > I have been running with Tijl's patch set for several days with great > > results. Testing has shown that the patches resolve both issues and I > > now see only 11 CPU speeds, all of those below the lower CPU clock speed > > are at that lower speed. Thus far I have seen no negative issues. The > > temperature of my system is noticeably cooler when not running something > > that is compute intensive. > > I'm working on reviewing and perhaps rewriting some of the patches. > They may work fine but there are some subtle issues, for instance, with > future systems that support more than one relative driver. The goals > are correct but the implementation needs a little work. No problem. I was just confirming that the patch was working well on a system using TCC and SpeedStep. I have only given the actual patch a quick scan to confirm that it did pretty much what was claimed. "More than one relative driver"? I had never considered that, but I can see the possibility. Guess that's why Bruno and you are doing this and I'm not. (Well, the fact that I write ugly code and have never read all of the ACPI spec has something to do with it, too.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050811145258.10F615D08>