Date: Mon, 25 Apr 2011 14:45:14 +0200 From: Bartosz Fabianowski <freebsd@chillt.de> To: Ian Smith <smithi@nimnet.asn.au> Cc: freebsd-stable@freebsd.org, John <john@theusgroup.com>, Jeremy Chadwick <freebsd@jdc.parodius.com> Subject: Re: System extremely slow under light load Message-ID: <4DB56CDA.50504@chillt.de> In-Reply-To: <20110425184728.C73992@sola.nimnet.asn.au> References: <4DA596D3.1090803@chillt.de> <op.vt1efdn68527sy@pinky> <BANLkTik5Jq1QP776xQ0zQvQ5MKYe4LQZUA@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DB56CDA.50504>