Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 13 Dec 2007 09:58:53 -0500
From:      "Ken Menzel" <kenfreebsd@icarz.com>
To:        "Nate Lawson" <nate@root.org>
Cc:        freebsd-acpi@freebsd.org
Subject:   Re: CURRENTand releng_7 kernel makes the system run very very hot
Message-ID:  <046801c83d98$addf8750$8adb7bd1@icarz.com>
References:  <13a701c83ce4$e94bfb20$8adb7bd1@icarz.com> <4760B444.4020302@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- 
From: "Nate Lawson" <nate@root.org>
To: "Ken Menzel" <kenm@icarz.com>
Cc: <freebsd-acpi@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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to 
> "freebsd-acpi-unsubscribe@freebsd.org"
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?046801c83d98$addf8750$8adb7bd1>