Fedora18的cpufreq bug

# cpupower frequency-info
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0 1 2 3
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 10.0 us.
hardware limits: 933 MHz - 2.40 GHz
available frequency steps: 2.40 GHz, 2.27 GHz, 2.13 GHz, 2.00 GHz, 1.87 GHz, 1.73 GHz, 1.60 GHz, 1.47 GHz, 1.33 GHz, 1.20 GHz, 1.07 GHz, 933 MHz
available cpufreq governors: conservative, userspace, powersave, ondemand, performance
current policy: frequency should be within 933 MHz and 960 MHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 933 MHz (asserted by call to hardware).
boost state support:
Supported: no
Active: no
1800 MHz max turbo 2 active cores
1800 MHz max turbo 1 active cores

/sys/devices/system/cpu/cpu0/cpufreq/bios_limit里面的值是正常的。

以前我在FreeBSD下也遇到过这种bug,为了省电而自动降低cpu频率,结果一直锁死在一个我无法忍受的低频下(无论CPU负载有多高)。但是FreeBSD下很轻易的就结果了,卸载相关模块即可。fedora这个2B,竟然把这个模块给内置在kernel中了,而且没有办法通过启动时的命令行参数禁用。

于是我正在根据这份文档重新编译kernel:https://fedoraproject.org/wiki/Building_a_custom_kernel

God bless me…

update:

我的CPU是Intel i3 M370,family确实是6,编译kernel的时候把CPU type选成Core 2,结果启动就panic了…… 只好选成generic 64位再编译一次

update:

去Y司之后发现它们大量DELL的服务器存在此问题。改下BIOS设置之后,为我部门能节省一半数量的服务器。真可怕!

此博客中的热门博文

在windows下使用llvm+clang

少写代码,多读别人写的代码

tensorflow distributed runtime初窥