Date: Wed, 27 Feb 2008 23:14:53 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: "Alexandre \"Sunny\" Kovalenko" <alex.kovalenko@verizon.net> Cc: acpi@freebsd.org Subject: Re: How to disable acpi thermal? Message-ID: <Pine.GSO.4.64.0802272259510.14806@sea.ntplx.net> In-Reply-To: <1203646096.16055.22.camel@RabbitsDen> References: <Pine.GSO.4.64.0801142156360.24324@sea.ntplx.net> <1200369199.2054.38.camel@RabbitsDen> <Pine.GSO.4.64.0801151525160.29868@sea.ntplx.net> <1203131179.833.32.camel@RabbitsDen> <Pine.GSO.4.64.0802201711090.7855@sea.ntplx.net> <1203549287.1019.43.camel@RabbitsDen> <Pine.GSO.4.64.0802201825100.7855@sea.ntplx.net> <1203555741.1019.50.camel@RabbitsDen> <Pine.GSO.4.64.0802202012180.7855@sea.ntplx.net> <1203646096.16055.22.camel@RabbitsDen>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 21 Feb 2008, Alexandre "Sunny" Kovalenko wrote: > > On Wed, 2008-02-20 at 20:14 -0500, Daniel Eischen wrote: >> On Wed, 20 Feb 2008, Alexandre \Sunny\ Kovalenko wrote: >> >>> >>> On Wed, 2008-02-20 at 18:48 -0500, Daniel Eischen wrote: >>>> On Wed, 20 Feb 2008, Alexandre \Sunny\ Kovalenko wrote: >>>> >>>>> I assume (possibly incorrectly) that 1) your CPU is capable of the >>>>> frequency throttling and 2) you are using frequency governor of some >>>>> sort (see cpufreq(4) for detail). If this is not the case, the change >>>>> will not help. >>>> >>>> I don't know about 1): >>>> >>>> CPU: Intel Pentium III (933.08-MHz 686-class CPU) >>>> Origin = "GenuineIntel" Id = 0x686 Stepping = 6 >>>> Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE> >>>> >>>> and 2), no, I'm not using a frequency governor from what I can >>>> tell. >>>> >>>> $ sysctl -a | grep dev.cpu >>>> dev.cpu.0.%desc: ACPI CPU >>>> dev.cpu.0.%driver: cpu >>>> dev.cpu.0.%location: handle=\_PR_.CPU0 >>>> dev.cpu.0.%pnpinfo: _HID=none _UID=0 >>>> dev.cpu.0.%parent: acpi0 >>>> dev.cpu.0.cx_supported: C1/0 >>>> dev.cpu.0.cx_lowest: C1 >>>> dev.cpu.0.cx_usage: 100.00% >>>> >>>> $ sudo kldload /boot/kernel/cpufreq.ko >>>> >>>> $ sysctl -a | grep dev.cpu >>>> dev.cpu.0.%desc: ACPI CPU >>>> dev.cpu.0.%driver: cpu >>>> dev.cpu.0.%location: handle=\_PR_.CPU0 >>>> dev.cpu.0.%pnpinfo: _HID=none _UID=0 >>>> dev.cpu.0.%parent: acpi0 >>>> dev.cpu.0.cx_supported: C1/0 >>>> dev.cpu.0.cx_lowest: C1 >>>> dev.cpu.0.cx_usage: 100.00% >>>> >>>> >>>>> Also, since I have sent you that change, I have learned that setting >>>>> hw.acpi.thermal.user_override=1 and hw.acpi.thermal.tz0._PSV=85C might >>>>> accomplish the same thing as the ASL change. I saw it working for the >>>>> thermal zone which already had sensible _PSV, but I have no hardware to >>>>> try this approach when _PSV is not present in the ASL. >>>> >>>> Well, this is a server board, not a laptop, so I'm not sure >>>> it even has CPU throttling. >>>> >>> As far as I can tell from the stuff above -- it does not. I was confused >>> by presence of some pieces in the ASL, which would normally indicate >>> that it does. One thing, which surprises me, is that with the lack of >>> throttling and, what appears to be single speed fan or even a heatsink, >>> I do not see how its thermal mode could behave differently in the >>> presence of the load. Could you, please, send me output of the sysctl >>> machdep. >> >> $ sysctl machdep >> machdep.enable_panic_key: 0 >> machdep.adjkerntz: 0 >> machdep.wall_cmos_clock: 0 >> machdep.disable_rtc_set: 0 >> machdep.conspeed: 9600 >> machdep.gdbspeed: 9600 >> machdep.conrclk: 1843200 >> machdep.disable_mtrrs: 0 >> machdep.guessed_bootdev: 2687500288 >> machdep.cpu_idle_hlt: 1 >> machdep.prot_fault_translation: 0 >> machdep.panic_on_nmi: 1 >> machdep.kdb_on_nmi: 1 >> machdep.tsc_freq: 933073074 >> machdep.i8254_freq: 1193182 >> machdep.acpi_timer_freq: 3579545 >> machdep.acpi_root: 1009936 >> > OK, I give up. The only positive idea so far is that your CPU needed > these idle moments (machdep.cpu_idle_hlt: 1) to keep temperature under > the critical level. AFAICR 4.x did not know much of anything about ACPI, > so it did not exhibit any problems. > > To check whether this is the hardware issue or that of FreeBSD, you can > boot from some recent Linux LiveCD and run 'openssl speed aes -multi > 256', or some other CPU-intensive thing of you choice, and > 'cat /proc/acpi/thermal_zone/TZC0/temperature' periodically to see > whether temperature would raise as rapidly. It might not be a bad idea > to do the same (former) thing under FreeBSD to make sure that it does > indeed cause thermal shutdown ;) I've done this, to somewhat ambiguous results. I used OpenSUSE Live CD (V10.3 / KDE). So it booted into KDE just fine, and 'cat /proc/acpi/thermal_zone/TZC0/temperature' showed the temp ranging from 98C to 100C. When I ran 'openssl speed aes -multi 256' it (Linux) showed the temperature climb to as high as 104C, but still seemed to hover around 101-103C. It didn't shoot up much from the 99C. But all that was with KDE, so I don't know what the temp was without KDE running. In FreeBSD, using 'openssl speed aes -multi 256', the temp can climb as high as 117C (which is over the 110C _CRT cap). Since this is a server, I don't have any window manager running on it. > Another (and more dangerous) experiment would be to set > hw.acpi.thermal.user_override=1 and hw.acpi.thermal.tz0._CRT=150C and > see whether temperature would stabilize at some point above the old _CRT > value. This might cost you a CPU, though... I've already done that. It stablizes at about 117 or so. Since there's not much more we can do, I'll just drop the issue. Maybe I'll see if I can get new server to replace it, kind of a shame since it's got much more horsepower than it currently needs. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0802272259510.14806>