vt(4) not power friendly? (was: High CPU temperature and high fans level)

Adrian Chadd adrian.chadd at gmail.com
Mon Aug 29 02:03:02 UTC 2016


On 18 August 2016 at 16:18, Lundberg, Johannes
<johannes at brilliantservice.co.jp> wrote:
> Hi
>
> I have been wondering about the same. I have a watt meter connected to my
> dev board and I can clearly see power consumption going down when VT is
> inactive.
>
> We should look into this.

... interesting. Hm. Can you boot vt into 80x25 text mode and test?


-a

>
> On Thu, Aug 18, 2016 at 2:44 PM, David Demelier <demelier.david at gmail.com>
> wrote:
>
>> On 20/07/16 15:20, Ian Smith wrote:
>>
>>> On Wed, 20 Jul 2016 12:46:32 +0200, David Demelier wrote:
>>>   > Le 18/07/2016 15:41, Ian Smith a écrit :
>>>   > > In freebsd-questions Digest, Vol 632, Issue 8, Message: 21
>>>   > > On Sun, 17 Jul 2016 11:59:32 +0200 David Demelier
>>>   > > <demelier.david at gmail.com> wrote:
>>>   > >   > 2016-07-17 0:25 GMT+02:00 Polytropon <freebsd at edvax.de>:
>>>   > >   > > On Sun, 17 Jul 2016 00:06:07 +0200, David Demelier wrote:
>>>   > >   > >> Hello,
>>>   > >   > >>
>>>   > >   > >> I was trying FreeBSD 10.3 on my laptop (hp probook 4510s)
>>> and was surprised
>>>   > >   > >> to see high CPU temperature and fans running high.
>>>   > >   > >>
>>>   > >   > >> No apps running, I get a temperature of 57C in
>>> dev.cpu.x.temperature and
>>>   > >   > >> fans run high (not able to get rpms).
>>>   > >   > >>
>>>   > >   > >> On a 4.6.3 Linux distro I get an average of 48C and fans are
>>> quite low.
>>>   > >   > >>
>>>   > >   > >> Both tests were kept in tty. No Xorg running just a boot and
>>> user login in
>>>   > >   > >> console.
>>>   > >   > >>
>>>   > >   > >> Do you have any clue?
>>>   > >   > >
>>>   > >   > > Did you enable powerd? It can slow down the CPU when the
>>> system
>>>   > >   > > is idle, and increase the CPU speed when needed. This should
>>> have
>>>   > >   > > an effect on CPU temperature and fan speed.
>>>   > >
>>>   > >   > Yes, I had powerd enabled, I tried -a adaptive, -a hiadaptive as
>>>   > >   > suggested by Erich but it seems that only -a min has some little
>>>   > >   > effect. I could get a temperature of 52C. I've tested back on
>>> Linux
>>>   > >   > and I got an average much lower (41C).
>>>   > >
>>>   > > We really need to see what speed the CPU is running at when idle.
>>>   > >
>>>   > > I think the fans running high - presumably from the sound and
>>> airflow? -
>>>   > > rules out the sort of sensor errors Arthur reported (ie below
>>> ambient :)
>>>   > > and I assume the box actually feels warmer .. 57C suggests a busy
>>> CPU or
>>>   > > two .. but then it is summer there; what background ambient temp.
>>> range?
>>>   >
>>>   > We have air-conditioning at work so ambient temperature is normal,
>>> somewhat
>>>   > between 24-28.
>>>
>>> Ok, just checking.  So the temperatures are indeed obviously excessive.
>>>
>>>   > >   > By the way the other sensors in hw.acpi.tz* are also much
>>> higher than
>>>   > >   > Linux (using lm_sensors). The highest value is my tz5 which is
>>> at 78C
>>>
>>> Isn't that tz2?  tz5 is only 55C in your listing (and not active), but
>>> tz2 is indeed 78C and working the fan moderately hard.
>>>
>>>   > >   > almost 5 seconds after boot while the maximum tz value in Linux
>>>   > >   > sensors is 55.
>>>   > >   >
>>>   > >   > I have no idea what's wrong. :(
>>>
>>>   > >   % sysctl hw.acpi
>>>   > >   % sysctl debug.acpi
>>>   > >   % sysctl dev.est        # assuming intel? if not, maybe
>>> dev.hwpstate?
>>>   > >   % sysctl dev.cpu        # best while idle, maybe plus when busier
>>>
>>>   > Thanks for your answer, here I posted the output of the sysctl
>>> variables you
>>>   > asked for:
>>>   >
>>>   > http://markand.fr/files/result.txt
>>>
>>> Thanks, that's a useful format.  Well, a couple of things ..
>>>
>>>   > I've ran them on a FreeBSD memstick, I needed to install a Linux
>>> distro until
>>>   > I can find a solution because this drains my battery a lot.
>>>
>>> But did you start powerd after the memstick boot?  From the CPU speed,
>>> assuming it was generally idle, I suspect not?
>>>
>>> The big surprise is that CPU frequency (at least when you asked) is at
>>> maximum (except for Turboboost mode) and that it's only using C1 state
>>> when halted.  C2 and C3 states provide a huge win for power consumption
>>> - and so proportionally less heat.  Alexander takes it to the limit at:
>>> https://wiki.freebsd.org/TuningPowerConsumption
>>>
>>> hw.acpi.cpu.cx_lowest: C1       # the 'master setting' for cx_lowest
>>>
>>> # ==> sysctl dev.cpu
>>> dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 14427us
>>> dev.cpu.1.cx_lowest: C1
>>> dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/162
>>> [..]
>>> dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 13756us
>>> dev.cpu.0.cx_lowest: C1
>>> dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/162
>>> dev.cpu.0.freq_levels: 2101/35000 2100/35000 1600/23888 1200/15000
>>> dev.cpu.0.freq: 2100
>>>
>>> Also noted that it's running on battery (which is good for this purpose)
>>> hw.acpi.acline: 0
>>> hw.acpi.battery.info_expire: 5
>>> hw.acpi.battery.units: 1
>>> hw.acpi.battery.state: 1
>>> hw.acpi.battery.time: 91        # can likely be doubled of better
>>> hw.acpi.battery.life: 79
>>>
>>>   > The average temperature was 50C, a bit less than the installed
>>> version on
>>>   > hard drive where I have seen higher values. This is interesting. I
>>> will
>>>   > double check if something else makes the CPU more busy.
>>>
>>> Well you need to duplicate basic conditions when booted from memstick;
>>> after boot, as root you should be able to:
>>>
>>>   # service powerd onestart
>>>   # sysctl hw.acpi.cpu.cx_lowest=Cmax
>>>
>>> and then observe dev.cpu.0.freq and dev.cpu.0.cx_usage ..
>>>
>>> Though whenever you plug it in, or unplug it, you'll have to set the
>>> sysctl again, unless you update the settings in /etc/rc.conf (possible?)
>>>
>>> Which should a) have it drop back to 1200 MHz and b) allow it to use C2
>>> and probably C3 .. you might check dmesg for any mention of 'C2' or 'C3'
>>> as certain combinations of chosen timecounter can limit C3 or even C2
>>> use, and will say so (usually to do with use of the TSC as timecounter)
>>>
>>> On 9.3 one still had to explicily set these:
>>> !grep cx /etc/defaults/rc.conf
>>> performance_cx_lowest="HIGH"    # Online CPU idle state
>>> economy_cx_lowest="HIGH"        # Offline CPU idle state
>>> !grep cx /etc/rc.conf
>>> performance_cx_lowest=C3
>>> economy_cx_lowest=C3
>>>
>>> But on head sources from a couple of months ago:
>>> !grep cx /usr/head/src/etc/defaults/rc.conf
>>> performance_cx_lowest="C2"      # Online CPU idle state
>>> economy_cx_lowest="Cmax"        # Offline CPU idle state
>>>
>>> So you might want to check what is there for 10.3?  Setting both 'Cmax'
>>> (or at least to C2) should be safe, the head defaults above are likely
>>> more conservative for a few boxes that aren't happy with C3 and higher.
>>>
>>> If that works, with powerd running CPU at 1200 MHz, it should save lots
>>> of power and run plenty cooler.  Good luck!
>>>
>>> Warner Losh has suggested disabling Turbo mode on these if having heat
>>> problems, by adding (in your case) '-M 2100' to powerd_flags, but that
>>> might be something for later.  Meanwhile go for C2 and C3+ if possible.
>>>
>>> As for fans, tz2 and tz0 are the only ones with 'active' cooling, though
>>> tz2 is the only one also with passive cooling, so is most probably the
>>> CPU/s - see acpi_thermal(4).
>>>
>>> This one doesn't turn on passive cooling (ie slowing the CPU) until only
>>> 3C below critical shutdown temperature, which seems a bit close to me.
>>>
>>> At that moment it was above 45C and below 62C, so running at level 3.
>>>
>>> hw.acpi.thermal.tz2._TSP: 300
>>> hw.acpi.thermal.tz2._TC2: 2
>>> hw.acpi.thermal.tz2._TC1: 1
>>> hw.acpi.thermal.tz2._ACx: 84.0C 74.0C 62.0C 45.0C 38.0C 30.0C -1 -1 -1 -1
>>> hw.acpi.thermal.tz2._CRT: 108.0C
>>> hw.acpi.thermal.tz2._HOT: -1
>>> hw.acpi.thermal.tz2._PSV: 105.0C
>>> hw.acpi.thermal.tz2.thermal_flags: 0
>>> hw.acpi.thermal.tz2.passive_cooling: 1
>>> hw.acpi.thermal.tz2.active: 3
>>> hw.acpi.thermal.tz2.temperature: 53.0C
>>>
>>> This fan is also active at level 3 (0-based, so above 72C, with 3 higher
>>> speeds to go).  It can be hard to tell what TZ matches what 'device'.
>>>
>>> hw.acpi.thermal.tz0._TSP: -1
>>> hw.acpi.thermal.tz0._TC2: -1
>>> hw.acpi.thermal.tz0._TC1: -1
>>> hw.acpi.thermal.tz0._ACx: 105.0C 96.0C 87.0C 72.0C 64.0C 57.0C 30.0C -1
>>> -1 -1
>>> hw.acpi.thermal.tz0._CRT: 108.0C
>>> hw.acpi.thermal.tz0._HOT: -1
>>> hw.acpi.thermal.tz0._PSV: -1
>>> hw.acpi.thermal.tz0.thermal_flags: 0
>>> hw.acpi.thermal.tz0.passive_cooling: 0
>>> hw.acpi.thermal.tz0.active: 3
>>> hw.acpi.thermal.tz0.temperature: 78.0C
>>>
>>> That one seems pretty high.  I'd suspect the GPU(/s?) but you're not
>>> running X, so hmmm .. definitely not CPU though.
>>>
>>> cheers, Ian
>>>
>>
>> Hello all,
>>
>> Sorry for this late response, I was in vacation.
>>
>> I've spent some time into this problem again, and I think I have found the
>> culprit. I first disabled completely the new console driver vt(4) to use
>> the old syscons and the CPU coretemp temperature immediately fell.
>>
>> Running with vt(4) and radeonkms loaded: average of 47°, no X, just a
>> plain tty with nothing running.
>>
>> Running with syscons: average of 38°.
>>
>> That's why I've CC'ed to freebsd-x11@,
>>
>> Is there power issue in the new vt(4) driver? I've also tried with
>> textmode with the same results.
>>
>> Regards,
>>
>> --
>> David Demelier
>> _______________________________________________
>> freebsd-x11 at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>> To unsubscribe, send any mail to "freebsd-x11-unsubscribe at freebsd.org"
>>
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 秘密保持について:この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
> もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
> 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
> ---
> CONFIDENTIALITY NOTE: The information in this email is confidential
> and intended solely for the addressee.
> Disclosure, copying, distribution or any other action of use of this
> email by person other than intended recipient, is prohibited.
> If you are not the intended recipient and have received this email in
> error, please destroy the original message.
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"


More information about the freebsd-x11 mailing list