ACPI problems op ASrock

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

ACPI problems op ASrock

Arthur van der Peijl
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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ACPI problems op ASrock

Kevin Oberman-4
On Fri, Sep 25, 2015 at 11:39 AM, Arthur van der Peijl <
[hidden email]> 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
<https://wiki.freebsd.org/TuningPowerConsumption> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ACPI problems op ASrock

Arthur van der Peijl
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@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@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@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@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@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 <[hidden email]> het volgende geschreven:

> On Fri, Sep 25, 2015 at 11:39 AM, Arthur van der Peijl <[hidden email]> 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
>
>

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ACPI problems op ASrock

John Baldwin
On Saturday, September 26, 2015 10:17:20 AM Arthur van der Peijl wrote:
> Thank you for assistance: powerd must clearly not be my focus: the CPU stays high and thus cannot go into idle mode.

Yes, I don't think tcc or throttling is related here.  Your issue is that something is
queueing tasks to the ACPI task queue threads (or a task is getting stuck in a busy
loop).  AFAIK there isn't really a great way currently to see which tasks are being
queued to a taskqueue and how long they are running.  It might be a nice thing to add
some KTR traces for, to log how long tasks run on a given taskqueue thread (I added
something a while back for callouts so they show up in schedgraph with the function
pointer and you can then use a debugger to map that pointer to a symbol name).

As an initial guess you might try identifying tasks that can be queued and adding some
stat counters exported via sysctl for different functions.

--
John Baldwin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ACPI problems op ASrock

Ian Smith-12
In reply to this post by Arthur van der Peijl
On Sat, 26 Sep 2015 10:17:20 +0200, Arthur van der Peijl wrote:
 > Thank you for assistance: powerd must clearly not be my focus: the
 > CPU stays high and thus cannot go into idle mode.

 > No need to change performance_cx_lowest as I just have a Pentium
 > G3220 running.
 >
 > [root@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@zfsguru /home/ssh]# sysctl dev.cpu.0.cx_lowest=C8
 > dev.cpu.0.cx_lowest: C8 -> C8

You really need to set hw.acpi.cpu.cx_lowest=C8 instead; this is then
propogated to dev.cpu.*.cx_lowest, updated when /etc/rc.d/power_profile
runs on losing or regaining mains power.  However, that won't help here.

 > We're already there. The document described some other setting which
 > could be read:
 >
 > [root@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?

I don't follow this either, and don't recall seeing different C-states
available on different CPUs?  If cpu1 has only C1, I can't see how cpu0
could ever use C2 - with its real win in terms of power consumption - as
all CPUs are now set to the same C-state (and P-state) as far as I know.

Is cpu1 a real CPU, or HTT? Perhaps show the CPU detection details from
dmesg.  powerd with standard parameters will always run at top speed
with the CPU usage/idle figures you quoted; you could get it to run
slower if you adjusted -i and -r settings, as an immediate workaround.

But listen to John about debugging the ACPI tasks CPU usage issue ..

cheers, Ian
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ACPI problems op ASrock

Arthur van der Peijl

On 29 sep. 2015, at 16:42  Ian Smith <[hidden email]> wrote:

> On Sat, 26 Sep 2015 10:17:20 +0200, Arthur van der Peijl wrote:
> <cut>
>> We're already there. The document described some other setting which
>> could be read:
>>
>> [root@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?
>
> I don't follow this either, and don't recall seeing different C-states
> available on different CPUs?  If cpu1 has only C1, I can't see how cpu0
> could ever use C2 - with its real win in terms of power consumption - as
> all CPUs are now set to the same C-state (and P-state) as far as I know.
>
> Is cpu1 a real CPU, or HTT? Perhaps show the CPU detection details from
> dmesg.  powerd with standard parameters will always run at top speed
> with the CPU usage/idle figures you quoted; you could get it to run
> slower if you adjusted -i and -r settings, as an immediate workaround.
>

Took CPU and ACPI related messages from dmesg:

CPU: Intel(R) Pentium(R) CPU G3220 @ 3.00GHz (2993.38-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306c3  Family=0x6  Model=0x3c  Stepping=3
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x4ddaebbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,<b11>,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x21<LAHF,ABM>
  Structured Extended Features=0x2603<FSGSBASE,TSCADJ,ERMS,INVPCID,NFPUSG>
  XSAVE Features=0x1<XSAVEOPT>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
ACPI APIC Table: <ALASKA A M I>
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:  2
acpi0: <ALASKA A M I> on motherboard
acpi0: Power Button (fixed)
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
pcib2: <ACPI PCI-PCI bridge> irq 16 at device 1.1 on pci0
pci2: <ACPI PCI bus> on pcib2
pcib3: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
pci3: <ACPI PCI bus> on pcib3
pcib4: <ACPI PCI-PCI bridge> irq 18 at device 28.2 on pci0
pci4: <ACPI PCI bus> on pcib4
pcib6: <ACPI PCI-PCI bridge> irq 19 at device 28.7 on pci0
pci6: <ACPI PCI bus> on pcib6
pcib7: <ACPI PCI-PCI bridge> irq 19 at device 0.0 on pci6
pci7: <ACPI PCI bus> on pcib7
acpi_button0: <Power Button> on acpi0
acpi_button1: <Sleep Button> on acpi0
acpi_tz0: <Thermal Zone> on acpi0
acpi_tz1: <Thermal Zone> on acpi0
coretemp0: <CPU On-Die Thermal Sensors> on cpu0
coretemp1: <CPU On-Die Thermal Sensors> on cpu1

> But listen to John about debugging the ACPI tasks CPU usage issue ..


That's where I'm stuck as a junior FreeBSD user: @John; can you suggest where to search for this? commands?

Regards,

Arthur van der Peijl


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"