From owner-freebsd-stable@FreeBSD.ORG Mon Apr 25 12:46:09 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C66C0106566C for ; Mon, 25 Apr 2011 12:46:09 +0000 (UTC) (envelope-from freebsd@chillt.de) Received: from dd16434.kasserver.com (dd16434.kasserver.com [85.13.137.111]) by mx1.freebsd.org (Postfix) with ESMTP id 588638FC1B for ; Mon, 25 Apr 2011 12:46:08 +0000 (UTC) Received: from taiko.lan (ppp-94-44.21-151.libero.it [151.21.44.94]) by dd16434.kasserver.com (Postfix) with ESMTPSA id 2A1E3188603F; Mon, 25 Apr 2011 14:46:06 +0200 (CEST) Message-ID: <4DB56CDA.50504@chillt.de> Date: Mon, 25 Apr 2011 14:45:14 +0200 From: Bartosz Fabianowski User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Thunderbird/3.1.9 MIME-Version: 1.0 To: Ian Smith References: <4DA596D3.1090803@chillt.de> <4DB44DA3.5060509@chillt.de> <4DB4589B.2020909@ksu.ru> <4DB45D6C.20203@chillt.de> <20110424182456.9DD03589@server.theusgroup.com> <4DB46ED4.2010500@chillt.de> <20110425004818.GA22579@icarus.home.lan> <4DB51F27.5010508@chillt.de> <20110425184728.C73992@sola.nimnet.asn.au> In-Reply-To: <20110425184728.C73992@sola.nimnet.asn.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org, John , Jeremy Chadwick Subject: Re: System extremely slow under light load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 12:46:09 -0000 > dev.cpu.X.freq does reflect the current frequency; I don't know whether > or how any internal clock throttling might be exposed. From what I have seen, dev.cpu.X.freq always retains the value I set it to. Internal CPU throttling does not seem to be reported this way. > a bit of hunting found your previous overheating > problems on a Dell Studio 1557 from April last year: > > and your eventual apparent solution which included some fiddling with > thermal parameters but primarily by disabling p4tcc and acpi_throttle Yes, that thread described the issues I had with my previous laptop before Dell exchanged it. I never posted an actual solution as I never found one. The problem only went away because the laptop went away. Disabling p4tcc and acpi_throttle may have seemed to address the problems at first - but longer-term evaluation showed that the issues persisted unchanged. > hint.p4tcc.0.disabled="1" > hint.acpi_throttle.0.disabled="1" I just tried this on my current Dell Studio 1558, with devastating results. The first boot attempt ended with the machine shutting down due to overheating while loading the kernel. I let it cool down a bit and then booted again. This time, I got to my desktop - with a CPU temperature of 95°C. If the DSDT was fixed, the machine would have shut down at this point. I only got down the temperature by reducing the maximal temperature to 1.2GHz again. With the above settings, the machine is idling at 80°C now and very sluggish - some internal throttling appears to be active again. > tz0 looks to be a fan. It seems unlikely that any temp. sensor inside a > machine with CPU temp. at 82C could possibly be as low as 26.8C, so this > value is likely as bogus as the 0.0C CPU reported by tz1. Yes, the 26.8°C is bogus. It never changes. Unfortunately, I have not found a way to fix this reading. The two thermal zones are implemented very differently in the DSDT and I have only managed to fix tz1. However, there is no second fan inside the laptop. I have taken it apart down to the last screw. There is one fan only and that corresponds to tz0. > This fan should come on at 55C and run fastest above 71C. If your CPU > is at 82C and the fan isn't running flat out, it'd overheat for sure. > tz0.active is -1, not running - but maybe the BIOS is controlling it? Yes, the BIOS appears to control the fan. The thresholds exposed via ACPI seem to be purely informative. Whether I fix the DSDT so that temperature readings work or not, the fan turns on at 55°C and speeds up at 71°C. It never spins down again after that as the CPU keeps running very hot. > _ACx is N/A here, unless there's a separate CPU fan? Anyway at bogus > 0.0C it's never going to trigger passive or active cooling. You said > before that with the fixed DSDT to get proper temperature reading here, > it shut down due to over temperature, which of course it should .. does > that fixed DSDT include fixing detected tz0 temperature .. if so the fan > might behave itself without having to use .thermal.user_override=1 See above: Fixing the DSDT makes tz1 work. tz0 remains broken. > Are you limiting it to 1333 manually, or with powerd's -M switch? I have tried both. It appears to make no difference whether I use powerd -M or just set dev.cpu.0.freq directly. > Clearly including p4tcc and/or acpi_throttle N*12.5% rates; compare to > dev.est.0.freq_settings below to figure the freqs added by throttling. > > Hopefully this machine will respond as well to disabling both methods as > your earlier one, as you reported here (same subject, later thread): See above: Unfortunately, the machine did nor respond well at all. Instead, it is overheating even worse. > Try using C2. It helps more with some CPUs than others, but it's worth > a try for further reducing heat, especially at idle. Ie in rc.conf: > > performance_cx_lowest="C2" > economy_cx_lowest="C2" I have set dev.cpu.X.cx_lowest="C2" at run-time. If I understand correctly, this should achieve the same effect. The CPU does not seem to ever make it to C2 though, even after I enable it: %sysctl dev.cpu | grep cx_usage dev.cpu.0.cx_usage: 100.00% 0.00% last 270us dev.cpu.1.cx_usage: 100.00% 0.00% last 399us dev.cpu.2.cx_usage: 100.00% 0.00% last 403us dev.cpu.3.cx_usage: 100.00% 0.00% last 404us dev.cpu.4.cx_usage: 100.00% 0.00% last 323us dev.cpu.5.cx_usage: 100.00% 0.00% last 313us dev.cpu.6.cx_usage: 100.00% 0.00% last 174us dev.cpu.7.cx_usage: 100.00% 0.00% last 137us > > dev.est.0.freq_settings: 1734/45000 1733/45000 1599/41741 1466/38582 > > 1333/35485 1199/32426 1066/29457 933/26552 > > With throttling disabled, those are what you should be left with for > dev.cpu.0.freq_levels. Yes, these are the frequencies I have available now. 1333 makes the machine idle around 85°C, 1999 leads to 78-80°C. - Bartosz