dev.cpu.0.freq disapeared

Ian Smith smithi at nimnet.asn.au
Mon Mar 23 06:03:43 UTC 2015


On Sun, 22 Mar 2015 20:11:36 +0300, Dmitry Sivachenko wrote:
 > > On 22 ÿÿÿÿÿÿÿÿÿÿ 2015 ÿÿ., at 17:11, Ian Smith <smithi at nimnet.asn.au> wrote:
 > > 
 > > Dmitry Sivachenko wrote:
 > >>> On 22 ÿÿÿÿÿÿÿÿÿÿ 2015 ÿÿ., at 8:53, Peter Jeremy <peter at rulingia.com> wrote:
 > >>> On 2015-Mar-22 00:58:55 +0300, Dmitry Sivachenko <trtrmitya at gmail.com> wrote:
 > >>>> I have a machine with the following processor:
 > >>>> CPU: Intel(R) Xeon(R) CPU           E5620  @ 2.40GHz (2400.14-MHz
 > >>>> K8-class CPU) Origin="GenuineIntel"  Id=0x206c2  Family=0x6 Model=0x2c  Stepping=2
 > >>> ...
 > >>>> After I upgraded to 10.1-STABLE #0 r279956, this sysctl disapeared. % sysctl dev.cpu.0.freq sysctl: unknown oid 'dev.cpu.0.freq': No such file or directory %
 > > 
 > >>> What OIDs do you have?  Does dev.cpu.0 exist?  How about dev.cpu?
 > >> dev.cpu.0 does exist.
 > > 
 > > It could be helpful to show all of:
 > > 
 > > % sysctl dev.cpu
 > > % sysctl dev.est	# if you have that?
 > > % sysctl -a | grep freq | grep -v time
 > > 
 > > both before and after re-enabling p4tcc.
 > 
 > Hello,
 > 
 > With #hint.p4tcc.0.disabled="1"  commented out:
 > 
 > % sysctl dev.cpu
 > dev.cpu.%parent: 

The parent should probably be listed.  On mine it's acpi0

 > dev.cpu.0.%desc: ACPI CPU
 > dev.cpu.0.%driver: cpu
 > dev.cpu.0.%location: handle=\_PR_.P001
 > dev.cpu.0.%pnpinfo: _HID=none _UID=0
 > dev.cpu.0.%parent: acpi0
 > dev.cpu.0.coretemp.delta: 67
 > dev.cpu.0.coretemp.resolution: 1
 > dev.cpu.0.coretemp.tjmax: 95.0C
 > dev.cpu.0.coretemp.throttle_log: 0
 > dev.cpu.0.temperature: 28.0C
 > dev.cpu.0.freq: 2400
 > dev.cpu.0.freq_levels: 2400/-1 2100/-1 1800/-1 1500/-1 1200/-1 900/-1 600/-1 300/-1
 > dev.cpu.0.cx_supported: C1/1/32 C2/3/96 C3/3/128
 > dev.cpu.0.cx_lowest: C1
 > dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 261us
[..]
 > dev.cpu.15.%desc: ACPI CPU
 > dev.cpu.15.%driver: cpu
 > dev.cpu.15.%location: handle=\_PR_.P016
 > dev.cpu.15.%pnpinfo: _HID=none _UID=0
 > dev.cpu.15.%parent: acpi0
 > dev.cpu.15.coretemp.delta: 67
 > dev.cpu.15.coretemp.resolution: 1
 > dev.cpu.15.coretemp.tjmax: 95.0C
 > dev.cpu.15.coretemp.throttle_log: 0
 > dev.cpu.15.temperature: 28.0C
 > dev.cpu.15.cx_supported: C1/1/32 C2/3/96 C3/3/128
 > dev.cpu.15.cx_lowest: C1
 > dev.cpu.15.cx_usage: 100.00% 0.00% 0.00% last 249us
 > 
 > % sysctl dev.est
 > dev.est.%parent: 

Right, so even with p4tcc enabled there's no dev.est, yet we then have 
dev.cpu.0.freq and freq_levels made available.  Hmm ..

 > % sysctl -a | grep freq | grep -v time
 > kern.acct_chkfreq: 15
 > device  cpufreq
 > net.inet.sctp.sack_freq: 2
 > debug.cpufreq.lowest: 0
 > debug.cpufreq.verbose: 0
 > machdep.i8254_freq: 1193182
 > machdep.tsc_freq: 2400132656
 > dev.cpu.0.freq: 2400
 > dev.cpu.0.freq_levels: 2400/-1 2100/-1 1800/-1 1500/-1 1200/-1 900/-1 600/-1 300/-1
 > dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1
[..]
 > dev.p4tcc.15.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1

 > dev.cpufreq.%parent: 
 > dev.cpufreq.0.%desc: 
 > dev.cpufreq.0.%driver: cpufreq
 > dev.cpufreq.0.%location: 
 > dev.cpufreq.0.%pnpinfo: 
 > dev.cpufreq.0.%parent: cpu0
[..]
 > dev.cpufreq.15.%desc: 
 > dev.cpufreq.15.%driver: cpufreq
 > dev.cpufreq.15.%location: 
 > dev.cpufreq.15.%pnpinfo: 
 > dev.cpufreq.15.%parent: cpu15

 > With hint.p4tcc.0.disabled="1" active (default in 10=STABLE now):
 > 
 > % sysctl dev.cpu
 > dev.cpu.%parent: 
 > dev.cpu.0.%desc: ACPI CPU
 > dev.cpu.0.%driver: cpu
 > dev.cpu.0.%location: handle=\_PR_.P001
 > dev.cpu.0.%pnpinfo: _HID=none _UID=0
 > dev.cpu.0.%parent: acpi0
 > dev.cpu.0.coretemp.delta: 66
 > dev.cpu.0.coretemp.resolution: 1
 > dev.cpu.0.coretemp.tjmax: 95.0C
 > dev.cpu.0.coretemp.throttle_log: 0
 > dev.cpu.0.temperature: 29.0C
 > dev.cpu.0.cx_supported: C1/1/32 C2/3/96 C3/3/128
 > dev.cpu.0.cx_lowest: C1
 > dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 428us
[..]
 > dev.cpu.1.temperature: 29.0C
 > dev.cpu.2.temperature: 32.0C
 > dev.cpu.3.temperature: 33.0C
 > dev.cpu.4.temperature: 33.0C
 > dev.cpu.5.temperature: 33.0C
 > dev.cpu.6.temperature: 31.0C
 > dev.cpu.7.temperature: 31.0C
 > dev.cpu.8.temperature: 22.0C
 > dev.cpu.9.temperature: 22.0C
 > dev.cpu.10.temperature: 31.0C
 > dev.cpu.11.temperature: 31.0C
 > dev.cpu.12.temperature: 25.0C
 > dev.cpu.13.temperature: 25.0C
 > dev.cpu.14.temperature: 27.0C

The above all seem the same, except temperatures.  The only difference I 
see is the lack of dev.cpu.0.freq and dev.cpu.0.freq_levels.

 > dev.cpu.15.%desc: ACPI CPU
 > dev.cpu.15.%driver: cpu
 > dev.cpu.15.%location: handle=\_PR_.P016
 > dev.cpu.15.%pnpinfo: _HID=none _UID=0
 > dev.cpu.15.%parent: acpi0
 > dev.cpu.15.coretemp.delta: 68
 > dev.cpu.15.coretemp.resolution: 1
 > dev.cpu.15.coretemp.tjmax: 95.0C
 > dev.cpu.15.coretemp.throttle_log: 0
 > dev.cpu.15.temperature: 27.0C
 > dev.cpu.15.cx_supported: C1/1/32 C2/3/96 C3/3/128
 > dev.cpu.15.cx_lowest: C1
 > dev.cpu.15.cx_usage: 100.00% 0.00% 0.00% last 7904us
 > 
 > % sysctl dev.est
 > dev.est.%parent: 

Do you have Enhanced Speedstep (EST), disabled in your BIOS settings?  
If so, just turn it on.  Then you should also be able to set running 
frequency to 'MAX performance' or similar there.

If not disabled, ie you have EST enabled in BIOS, that points to a real 
issue of EST detection.  And it still seems strange that enabling p4tcc 
is enough to have cpufreq(4) include OIDs for freq and freq_levels?

 > % sysctl -a | grep freq | grep -v time
 > kern.acct_chkfreq: 15
 > device  cpufreq
 > net.inet.sctp.sack_freq: 2
 > debug.cpufreq.lowest: 0
 > debug.cpufreq.verbose: 0
 > machdep.i8254_freq: 1193182
 > machdep.tsc_freq: 2400136744
 > 
 > 
 > Also I have this in dmesg which may be relevant:
 > 
 > p4tcc0: <CPU Frequency Thermal Control> on cpu0
 >  coretemp1: <CPU On-Die Thermal Sensors> on cpu1
 >  est1: <Enhanced SpeedStep Frequency Control> on cpu1
 >  est: CPU supports Enhanced Speedstep, but is not recognized.
 >  est: cpu_vendor GenuineIntel, msr 12
 >  device_attach: est1 attach returned 6
 > 
 > for each CPU.  The line starting with p4tcc apears only when I remove 
 > hint.p4tcc.0.disabled="1"

Right, this is still looking like you have EST disabled in BIOS.

 > > Are you not running powerd?  Of course powerd won't start if it can't
 > > get dev.cpu.0.freq but you can ordinarily use it to set lowest and/or
 > > highest freqs.  Once FreeBSD starts, BIOS settings should have little
 > > do with it, AFAIK, except how they might set freq before powerd starts.
 > 
 > No, I don't use powerd. I want my processor to always run at max speed.

Setting debug.cpufreq.lowest=2400 should also accomplish that without 
running powerd.  Enabling higher C-states (C2, C3 .. Cmax) would save a 
lot of power (ie, heat) without compromising performance, but that's a 
separate issue.

 > But I encountered situations when sometime system is running at 
 > 1200GHz instead of 2400 and it is fixed with BIOS updates. That is 
 > why I check dev.cpu.0.freq each time system reboot.

Well, your checking did expose this issue ..

 > My processor is Intel E5620 :
 > http://ark.intel.com/products/47925/Intel-Xeon-Processor-E5620-12M-Cache-2_40-GHz-5_86-GTs-Intel-QPI
 > 
 > It is not so ancient thing.

Right.  Looks like your board has two of these packages, and indeed it 
does support EST.  If you do have that enabled, we have a problem, and 
really need to see a verbose boot dmesg.  If not, you have a problem 
that can be easily fixed in BIOS settings :)

cheers, Ian


More information about the freebsd-stable mailing list