From owner-freebsd-stable@FreeBSD.ORG Sat May 23 14:40:30 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5052860 for ; Sat, 23 May 2015 14:40:29 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5614E164A for ; Sat, 23 May 2015 14:40:29 +0000 (UTC) Received: by lbbzk7 with SMTP id zk7so29265143lbb.0 for ; Sat, 23 May 2015 07:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6IzIFCodNBntDjzduFv7uwT+InPzKqI5RDgnLTKXM4w=; b=jkDG9SsY9EF23T0freFRvCXwRIppLbHlAqAht+Ljxz9d+/GdJqUQxrWfPWHp/B+sag GxlFOGbahQouTVIBg8/NXNvNI0bjPObLgp/09b/B7WhLjxsDR0/LFIH5Zax10Slg/uXO e0ZZ9TS2fDbKpkIFLn5kGFyfzRI9/QgWittEavu1ItuNARC8nI1Gy2W/MN8kQWAp+eb9 y8BMvasygVSw7RjAKTUHXSO3bs8u+F2hUxpPOOxmW2Se74lzrnpte2Ulksd51oY7fHIn EVfy04fkgTSoZQ+4zha5aj6f+1XddFVeieCyy9xTApC0YS54kxrQN7nuQnlRPt6c1Vfi CBCw== MIME-Version: 1.0 X-Received: by 10.152.22.34 with SMTP id a2mr10911115laf.59.1432392026818; Sat, 23 May 2015 07:40:26 -0700 (PDT) Received: by 10.152.137.193 with HTTP; Sat, 23 May 2015 07:40:26 -0700 (PDT) In-Reply-To: <20150523234646.R7173@sola.nimnet.asn.au> References: <555C71C8.4080007@gmx.com> <555EDBBB.4090107@gmx.com> <20150522104213.4e083225@nonamehost.local> <20150523014640.K7173@sola.nimnet.asn.au> <20150523163014.U7173@sola.nimnet.asn.au> <20150523234646.R7173@sola.nimnet.asn.au> Date: Sat, 23 May 2015 17:40:26 +0300 Message-ID: Subject: Re: CPU frequency doesn't drop below 1200MHz (like it used to) From: Kimmo Paasiala To: Ian Smith Cc: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 14:40:30 -0000 On Sat, May 23, 2015 at 5:15 PM, Ian Smith wrote: > On Sat, 23 May 2015 14:01:16 +0300, Kimmo Paasiala wrote: > > On Sat, May 23, 2015 at 10:00 AM, Ian Smith wrote: > > > On Fri, 22 May 2015 20:26:40 +0300, Kimmo Paasiala wrote: > > > > On Fri, May 22, 2015 at 8:19 PM, Ian Smith wrote: > > > > > On Fri, 22 May 2015 16:28:49 +0300, Kimmo Paasiala wrote: > > > > > > On Fri, May 22, 2015 at 10:42 AM, Ivan Klymenko wrote: > > > [..] > > > > >> Try changing the options in /boot/device.hints > > > > >> hint.acpi_throttle.0.disabled="0" > > > > >> hint.p4tcc.0.disabled="0" > > > > > > > > > > > Thanks, those also fixed powerd(8) for me that stopped working after > > > > > > upgrading to stable/10 from releng/10.1. Why are those setting > > > > > > suddenly needed now? > > > [..] > > > > > Can you say exactly in what way powerd stopped working then? > > > > > > > > Powerd(8) complained (excerpt from dmesg -a): > > > > > > > > Starting powerd. > > > > powerd: no cpufreq(4) support -- aborting: No such file or directory > > > > /etc/rc: WARNING: failed to start powerd > > > > > > > > Putting those two settings in loader.conf and rebooting fixed the > > > > problem and powerd started working again apparently because cpufreq(4) > > > > device was available again. > > > > > > Ok, if anabling acpi_throttle and/or p4tcc made cpufreq - and thus > > > powerd - work for you, then it seems likely that you do not have EST > > > enabled in your BIOS. Or at least, we've seen another instance where > > > that was the case, which was fixed by enabling EST (or however your > > > particular BIOS refers to it .. AMD for example use different terms). > > > > > > What CPU is this? In what machine? > > > > > > If EST (ono) IS enabled in your BIOS, this needs further investigation. > > > > > > As is, powerd may be running, but it's doing so highly inefficiently; > > > refer to Stefan, Adrian and Kevin's responses for details. > > > It's an Intel Atom running amd64 version of FreeBSD stable/10: > > > > FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1 > > r283292: Sat May 23 01:08:03 EEST 2015 > > root@firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC amd64 > > > > CPU: Intel(R) Atom(TM) CPU D510 @ 1.66GHz (1666.68-MHz K8-class CPU) > > Origin="GenuineIntel" Id=0x106ca Family=0x6 Model=0x1c Stepping=10 > > Features=0xbfebfbff > > Features2=0x40e31d > > AMD Features=0x20100800 > > AMD Features2=0x1 > > TSC: P-state invariant, performance statistics > > > > Powerd was working on 10.1-RELEASE but stopped working after upgrade > > to 10-STABLE and nothing was changed in BIOS settings. > > Which would be consistent with EST not being enabled in your BIOS; with > no EST, cpufreq(4) still checks for 'relative' drivers such as p4tcc or > acpi_throttle and uses that, as a last resort really; with those also > disabled, no cpufreq, so no powerd. Have you checked BIOS settings to > confirm that you do have SpeedStep (however termed) properly enabled? > > Please show `sysctl dev.cpu dev.est` and `sysctl -a | grep freq_levels` > > > However, reading the other replies to this thread I get the impression > > that powerd(8) doesn't actually save energy on this platform and I'm > > better off without it? > > No, I don't think that's correct; using deeper C-states is most likely a > bigger win, but higher than needed CPU freq will still use extra power, > so run hotter. `sysctl dev.cpu` will also reveal your C-state usage. > > Reason I'm pursuing this is that this change shouldn't hurt, but it will > flush out those cases where people were only getting cpufreq due to use > of a 'relative' cpufreq driver like p4tcc, unless EST's enabled in BIOS; > I suspect yours may be one such case :) If not, there's a bug to fix. > > cheers, Ian Looking deeper into this it appears I don't have speedstep (EST) support in the CPU it being a crappy Atom D510: http://ark.intel.com/products/43098 This the full 'sysctl dev.cpu' output: % sysctl dev.cpu dev.cpu.3.cx_usage: 100.00% last 65712us dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_supported: C1/1/0 dev.cpu.3.%parent: acpi0 dev.cpu.3.%pnpinfo: _HID=none _UID=0 dev.cpu.3.%location: handle=\_PR_.P004 dev.cpu.3.%driver: cpu dev.cpu.3.%desc: ACPI CPU dev.cpu.2.cx_usage: 100.00% last 41518us dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_supported: C1/1/0 dev.cpu.2.%parent: acpi0 dev.cpu.2.%pnpinfo: _HID=none _UID=0 dev.cpu.2.%location: handle=\_PR_.P003 dev.cpu.2.%driver: cpu dev.cpu.2.%desc: ACPI CPU dev.cpu.1.cx_usage: 100.00% last 12706us dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_supported: C1/1/0 dev.cpu.1.%parent: acpi0 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%location: handle=\_PR_.P002 dev.cpu.1.%driver: cpu dev.cpu.1.%desc: ACPI CPU dev.cpu.0.cx_usage: 100.00% last 3132us dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_supported: C1/1/0 dev.cpu.0.%parent: acpi0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%location: handle=\_PR_.P001 dev.cpu.0.%driver: cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.%parent: So I should keep those two hints in loader.conf to use p4tcc I guess? -Kimmo