CURRENTand releng_7 kernel makes the system run very very hot
Ken Menzel
kenfreebsd at icarz.com
Thu Dec 13 06:58:52 PST 2007
----- Original Message -----
From: "Nate Lawson" <nate at root.org>
To: "Ken Menzel" <kenm at icarz.com>
Cc: <freebsd-acpi at freebsd.org>
Sent: Wednesday, December 12, 2007 11:25 PM
Subject: Re: CURRENTand releng_7 kernel makes the system run very very
hot
> Ken Menzel wrote:
>> It has been suggested to me to move this thread from current to
>> acpi.
>>> From what I can tell the CPU's do not halt on idle. Top -SH from
>>> a
>> system booted for a few hours on releng_7 or on current shows hours
>> of
>> time used where as releng_6 used only minutes or seconds. This is
>> causing some sytems to overheat.
>>
>> I am trying to compile all the relevant information in this e-mail.
>> If I
>> have missed anything please let me kow. I can also provide ssh
>> access
>> to a developer who would like to see the problem. I see the
>> problem on
>> both AMD64 kernel and i386 kernel single and multi processor.
>>
>> Here is information I have gather so far: Is there anything else
>> needed
>> for the PR?
>
> Based on the information you sent privately, I don't see anything
> wrong.
> acpi_cpu_idle() is calling acpi_cpu_c1() as expected. There is no
> interrupt storm according to vmstat -i. So the question now is,
> "why
> doesn't the HLT instruction actually work?" Perhaps there is some
> CPU
> errata or BIOS configuration option you need to change to enable C1?
hmmm OK except I am seeing the same symptons (they are not overheating
in my case just using IDLE time) on all 3 releng_7 boxes and 2 that
were running 6.2 just fine. I can can downgrade it again and double
check. It's just not fun to bounce back and forth.
>
> What does sysctl dev.cpu say?
>
barclay# sysctl dev.cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU1
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1987
dev.cpu.0.freq_levels: 1987/-1 1738/-1 1490/-1 1241/-1 993/-1 745/-1
496/-1 248/ -1
dev.cpu.0.cx_supported: C1/0 C2/750
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% 0.00%
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.CPU2
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.cx_supported: C1/0 C2/750
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00% 0.00%
dev.cpu.2.%desc: ACPI CPU
dev.cpu.2.%driver: cpu
dev.cpu.2.%location: handle=\_PR_.CPU3
dev.cpu.2.%pnpinfo: _HID=none _UID=0
dev.cpu.2.%parent: acpi0
dev.cpu.2.cx_supported: C1/0 C2/750
dev.cpu.2.cx_lowest: C1
dev.cpu.2.cx_usage: 100.00% 0.00%
dev.cpu.3.%desc: ACPI CPU
dev.cpu.3.%driver: cpu
dev.cpu.3.%location: handle=\_PR_.CPU4
dev.cpu.3.%pnpinfo: _HID=none _UID=0
dev.cpu.3.%parent: acpi0
dev.cpu.3.cx_supported: C1/0 C2/750
dev.cpu.3.cx_lowest: C1
dev.cpu.3.cx_usage: 100.00% 0.00%
dev.cpu.4.%desc: ACPI CPU
dev.cpu.4.%driver: cpu
dev.cpu.4.%location: handle=\_PR_.CPU5
dev.cpu.4.%pnpinfo: _HID=none _UID=0
dev.cpu.4.%parent: acpi0
dev.cpu.4.cx_supported: C1/0 C2/750
dev.cpu.4.cx_lowest: C1
dev.cpu.4.cx_usage: 100.00% 0.00%
dev.cpu.5.%desc: ACPI CPU
dev.cpu.5.%driver: cpu
dev.cpu.5.%location: handle=\_PR_.CPU6
dev.cpu.5.%pnpinfo: _HID=none _UID=0
dev.cpu.5.%parent: acpi0
dev.cpu.5.cx_supported: C1/0 C2/750
dev.cpu.5.cx_lowest: C1
dev.cpu.5.cx_usage: 100.00% 0.00%
dev.cpu.6.%desc: ACPI CPU
dev.cpu.6.%driver: cpu
dev.cpu.6.%location: handle=\_PR_.CPU7
dev.cpu.6.%pnpinfo: _HID=none _UID=0
dev.cpu.6.%parent: acpi0
dev.cpu.6.cx_supported: C1/0 C2/750
dev.cpu.6.cx_lowest: C1
dev.cpu.6.cx_usage: 100.00% 0.00%
dev.cpu.7.%desc: ACPI CPU
dev.cpu.7.%driver: cpu
dev.cpu.7.%location: handle=\_PR_.CPU8
dev.cpu.7.%pnpinfo: _HID=none _UID=0
dev.cpu.7.%parent: acpi0
dev.cpu.7.cx_supported: C1/0 C2/750
dev.cpu.7.cx_lowest: C1
dev.cpu.7.cx_usage: 100.00% 0.00%
barclay#
What else can I try? Can I force the a different routine for halt?
Could this be related to this PR for overheating?
http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/117727
Am I tilting at windmills?
Thanks for your help Nate,
Ken
> --
> Nate
> _______________________________________________
> freebsd-acpi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to
> "freebsd-acpi-unsubscribe at freebsd.org"
>
More information about the freebsd-acpi
mailing list