CPU frequency doesn't drop below 1200MHz (like it used to)

Sat May 23 15:15:56 UTC 2015

Hm, no thermal monitoring and no speedstep. Could be dangerous/fun.

What's the output of sysctl dev.cpu.0 ?

-adrian

On 23 May 2015 at 07:40, Kimmo Paasiala <kpaasial at gmail.com> wrote:
> On Sat, May 23, 2015 at 5:15 PM, Ian Smith <smithi at nimnet.asn.au> wrote:
>> On Sat, 23 May 2015 14:01:16 +0300, Kimmo Paasiala wrote:
>>  > On Sat, May 23, 2015 at 10:00 AM, Ian Smith <smithi at nimnet.asn.au> wrote:
>>  > > On Fri, 22 May 2015 20:26:40 +0300, Kimmo Paasiala wrote:
>>  > >  > On Fri, May 22, 2015 at 8:19 PM, Ian Smith <smithi at nimnet.asn.au> wrote:
>>  > >  > > On Fri, 22 May 2015 16:28:49 +0300, Kimmo Paasiala wrote:
>>  > >  > >  > On Fri, May 22, 2015 at 10:42 AM, Ivan Klymenko <fidaj at ukr.net> 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 at 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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>>  >   Features2=0x40e31d<SSE3,DTES64,MON,DS_CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE>
>>  >   AMD Features=0x20100800<SYSCALL,NX,LM>
>>  >   AMD Features2=0x1<LAHF>
>>  >   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
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"