Date: Mon, 23 Mar 2015 17:03:34 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Dmitry Sivachenko <trtrmitya@gmail.com> Cc: Kevin Oberman <rkoberman@gmail.com>, FreeBSD Stable ML <stable@freebsd.org>, Peter Jeremy <peter@rulingia.com>, nwhitehorn@freebsd.org Subject: Re: dev.cpu.0.freq disapeared Message-ID: <20150323152431.W22641@sola.nimnet.asn.au> In-Reply-To: <97279AFB-7718-4080-9F18-155287216A04@gmail.com> References: <EE8D6553-4319-4CE1-8F73-3244C49F454C@gmail.com> <20150322055323.GA48710@server.rulingia.com> <77C8F6F7-2C25-4BC5-B373-11441AB58FAD@gmail.com> <550ECD9D.2030108@nimnet.asn.au> <97279AFB-7718-4080-9F18-155287216A04@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 22 Mar 2015 20:11:36 +0300, Dmitry Sivachenko wrote: > > On 22 ÿÿÿÿÿÿÿÿÿÿ 2015 ÿÿ., at 17:11, Ian Smith <smithi@nimnet.asn.au> wrote: > > > > Dmitry Sivachenko wrote: > >>> On 22 ÿÿÿÿÿÿÿÿÿÿ 2015 ÿÿ., at 8:53, Peter Jeremy <peter@rulingia.com> wrote: > >>> On 2015-Mar-22 00:58:55 +0300, Dmitry Sivachenko <trtrmitya@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150323152431.W22641>