ACPI problems op ASrock

Sat Sep 26 08:17:25 UTC 2015

Thank you for assistance: powerd must clearly not be my focus: the CPU stays high and thus cannot go into idle mode.

I worked thought the document which uncovers that most settings are already available in my system:

[root at zfsguru /home/ssh]# cat /etc/rc.conf | grep cx_
performance_cx_lowest="Cmax"
economy_cx_lowest="Cmax"

No need to change performance_cx_lowest as I just have a Pentium G3220 running.

[root at zfsguru /home/ssh]# cat /boot/loader.conf | grep hint.
hint.p4tcc.0.disabled="1"
hint.acpi_throttle.0.disabled="1"

Tried to change lowest level on running system: 

[root at zfsguru /home/ssh]# sysctl dev.cpu.0.cx_lowest=C8
dev.cpu.0.cx_lowest: C8 -> C8

We're already there. The document described some other setting which could be read:

[root at zfsguru /home/ssh]# sysctl dev.cpu | grep cx
dev.cpu.1.cx_usage: 100.00% last 5us
dev.cpu.1.cx_lowest: C8
dev.cpu.1.cx_supported: C1/1/1
dev.cpu.0.cx_usage: 100.00% 0.00% last 4us
dev.cpu.0.cx_lowest: C8
dev.cpu.0.cx_supported: C1/1/1 C2/2/117

I don't inderstand this. 100% CPU is my main issue, created by {acpi_task} in the kernal.
However -> CPU1 supports different states as CPU0? Or is this a summary of last states?

You last remark about frequencies:

[root at zfsguru /home/ssh]# sysctl dev.cpu | grep freq
dev.cpu.0.freq_levels: 3000/53000 2900/50301 2700/46082 2600/43525 2400/39557 2300/37137 2100/33398 2000/31112 1800/27610 1700/25455 1500/22171 1400/20144 1200/17084 1100/15181 900/12329 800/10550
dev.cpu.0.freq: 3000

As I understand there could be better effective power management be available. Should that resolve my high CPU issue? Or is it caused by bad Asrock BIOS tables? 

As only my high CPU generating {acpi_task} stops, I'll get a better - more power effective - system using less Watts.

Regards,

Arthur

Op 26 sep. 2015, om 01:09 heeft Kevin Oberman <rkoberman at gmail.com> het volgende geschreven:

> On Fri, Sep 25, 2015 at 11:39 AM, Arthur van der Peijl <aavanderpeijl at gmail.com> wrote:
> Hello,
> 
> In May I started with 10.0-Release on an ASrock E3C224D4I-14S.
> The system had low power consumption and powerd(8) did a good job lowering the CPU frequency.
> 
> However starting from 10.1 (and now 10.2-release) I keep getting high CPU consumption due to a process called {acpi task}.
> 
> BIOS upgrades or changes didn't help. Disabling ACPI results in system halt at startup.
> Does anybody have an idea to solve this? It seems that the ACPI process in FreeBSD is changed, which my motherboard cannot handle (or the mb has wrong ACPI tables?).
> 
> top -SH output:
> ----
> last pid: 41184;  load averages:  1.71,  1.75,  1.64                                          up 8+14:05:40  10:00:16
> 691 processes: 7 running, 663 sleeping, 21 waiting
> CPU:  0.8% user,  0.0% nice, 62.7% system,  0.0% interrupt, 36.5% idle
> Mem: 90M Active, 4310M Inact, 11G Wired, 18M Cache, 144K Buf, 497M Free
> ARC: 9991M Total, 1364M MFU, 7997M MRU, 4841K Anon, 36M Header, 588M Other
> Swap: 2048M Total, 2048M Free
> 
>   PID USERNAME    PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
>   11 root        155 ki31     0K    32K RUN     1 122.7H  62.99% idle{idle: cpu1}
>     0 root          8    0     0K  7088K RUN     1  73.2H  36.87% kernel{acpi_task_1}
>     0 root          8    0     0K  7088K RUN     0  73.3H  36.18% kernel{acpi_task_0}
>     0 root          8    0     0K  7088K RUN     0  73.2H  35.60% kernel{acpi_task_2}
>   11 root        155 ki31     0K    32K RUN     0  67.6H  34.08% idle{idle: cpu0}
> 1024 mysql        20    0   266M 69624K RUN     1   0:37   0.10% mysqld{mysqld}
>   12 root        -60    -     0K   336K WAIT    0  11:18   0.00% intr{swi4: clock}
> 1149 root         20    0   500M 90016K sbwait  0   6:15   0.00% mongod{mongod}
> 1149 root         20    0   500M 90016K sbwait  1   6:13   0.00% mongod{mongod}
> 1149 root         20    0   500M 90016K sbwait  0   6:12   0.00% mongod{mongod}
>   687 root         20    0  4560M   363M uwait   1   5:31   0.00% java{java}
> ----
> 
> Regards,
> 
> Arthur
> 
> I have not noted this exact behavior, so this MIGHT not work, but the subject of power management seems to keep coming up. For a good discussion of the subject, read mav@'s FreeBSD wiki article on the subject. It's slightly (but only slightly) dated.
> 
> To fix your immediate issue, try adding the following to /etc/rc.conf:
> performance_cx_lowest="Cmax"
> economy_cx_lowest="Cmax"
> 
> NOTE: In the case of very large multiprocessor systems with 32 or more CPUs, you might get a nasty performance hit and should instead use:
> performance_cx_lowest="C2"
> economy_cx_lowest="Cmax"
> 
> Please DON'T enable TCC and/or throttling and C-states together! On some processors this can cause deadlocks. Intel never expected TCC/throttling to be used the way FreeBSD did.
> 
> For desktop and laptop use, "Cmax" is always the way to go. It really, really reduces power consumption.
> 
> Finally, if this fails, you can restore TCC by adding "hint.acpi_p4tcc.0.disabled=0" to /boot/loader.conf, but never combine this with setting either cx_lowest value in rc.conf. This change will require a reboot.
> 
> You can change this on a running system with "sysctl dev.cpu.0.cx_lowest=C8" to enable C-states or C1 to disable them. No need to re-boot.
> 
> Read on for more gory details. Note that I am at least partly responsible for the long-term brokenness of FreeBSD power management as I did laboratory testing of it when I was at Lawrence Berkeley Lab, but did not really understand the differences between the test-bed and the real world. 
> 
> Throttling is not and never has been a tool for power management. It was created by Intel as a method of thermal management and the implementation was manual. That is, some external process had to activate it. It was replaced in 2000 by TCC (Thermal Control Circuit) which did the exact same thing, but was entirely internal to the processor and was thus consistent and uniformly implemented. Throttling was still present for compatibility, but is really, really obsolete.
> 
> Both throttling and TCC so the same thing. They reduce the heat generated by skipping 'N' of every 8 clock cycles. They don't actually change the clock speed. EST, which actually does slow the clock as well as reducing the core voltage should still provide a a few clock speeds. The number is dependent on the particular CPU, but usually between 3 and 8. It does save power, but not very effectively.
> 
> Unfortunately, many thought that throttling was a way to do power management. In fact, except in a few real-time edge cases, it is totally ineffective for that purpose.
> 
> The problem you are having is probably that enabling the newer, really effective power management tool was not committed to 10.2 when TCC was disabled. It is now in HEAD and I am hoping to see it in 10.3 as well as 11. (I'm not a committer, so I only can go on what I've been told by the one who committed disabling TCC.)
> 
> C-states do not change the clock speed. You will only have a small set of frequencies reported as those will be REAL clock speeds from EST, not the synthetic ones shown when using throttling/TCC, so the number of them shown by default on 10.2 will be 1/8th of when was shown by prior versions.
> 
> I you do need to do this, please let us know. That should not be happening!
> 
> I am now working (slowly) on a power management section of the handbook which will do a better job of explaining the issues.
> --
> Kevin Oberman, Part time goatherd and retired Network Engineer
> 
> 