From owner-freebsd-current@FreeBSD.ORG Thu Feb 24 21:41:06 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE69816A4CE; Thu, 24 Feb 2005 21:41:06 +0000 (GMT) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4D6B43D46; Thu, 24 Feb 2005 21:41:05 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.128] ([192.168.2.2]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j1OLenEc084803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Feb 2005 22:40:50 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <421E49D9.60803@portaone.com> Date: Thu, 24 Feb 2005 23:40:41 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <20050224011924.992A65D07@ptavv.es.net> <421DA0B5.4060705@portaone.com> <421E42F2.6010105@root.org> In-Reply-To: <421E42F2.6010105@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.80/685/Wed Jan 26 10:08:24 2005 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean cc: acpi@FreeBSD.ORG cc: current@FreeBSD.ORG Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2005 21:41:06 -0000 Nate Lawson wrote: > Maxim Sobolev wrote: > >> Kevin Oberman wrote: >> >>> No joy. I set it to 262 and it was fine. The next step killed the system >>> again. >>> >>> I'm also concerned that taking TCC out of automatic mode might not be a >>> great idea, at least until things like _PSV are supported. When I do a >>> buildkernel, buildworld or any big compile job, I need to slow down the >>> CPU to keep the CPU form frying. It quickly jumps to 185 F. or higher if >>> I don't. If I understand automatic TCC, it should throttle the CPU all >>> by itself to prevent this. >> >> >> >> Taking TCC out of automatic mode doesn't disable thermal controlling >> circuitry completely, so that if the processor overheats it will shut >> down the machine anyway: >> >> --- >> Regardless of enabling of the automatic >> or On-Demand modes, in the event of a catastrophic cooling failure, >> the processor will >> automatically shut down when the silicon has reached a temperature of >> approximately >> 135 °C. At this point the system bus signal THERMTRIP# will go active >> and stay active >> until RESET# has been initiated. --- > > > Correct. Even more so, automatic mode continues to override On-Demand > mode if there is a more moderate thermal condition than THERMTRIP#: > > "On-Demand mode may be used at the same time Automatic mode is enabled, > however, if the system tries to enable the TCC via On-Demand mode at the > same time automatic mode is enabled AND a high temperature condition > exists, the duty cycle of the automatic mode will override the duty > cycle selected by the On-Demand mode." > > Since automatic mode is set by the BIOS before we even boot, things > should be fine. Well, this is quite tricky part of the spec. My reading is that the paragraph above applies only to situation if you are trying to set on-demand mode when both automatic mode is in effect *and* high temperature condition already exists, in that case automatic mode will win and override any manual settings. However, in the case when you have on-demand mode already on and high temperature condition emerges it will have no effect on duty cycle until THERMTRIP# kicks in. That's in my view explains why there is big AND in the text above. -Maxim