It is now possible to compile and install a linux kernel module that will boost the speed of the FSB from the default 70 MHz to 100 MHz, thus boosting the speed of the system. The speed of the CPU will be boosted to the 900 MHz that has been advertised for the Eee PC.
WARNING: The kernel modules and procedures described here are experimental and are for experienced users only. In attempting these procedures, you are likely to experience system lockups until you can determine a reliable configuration for your system.
Note for 2G Surf: Overclocking with eee.ko linux kernel module doesn't seem to work with Eee PC 2G Surf because different clockchip (CY28442) than in 4G. Unconfirmed rumors though says that under-/overclocking via acpi is possible with bios version < 0124 (by Asus documentation) or in Windows.
http://forum.eeeuser.com/viewtopic.php?pid=187234
http://forum.eeeuser.com/viewtopic.php?id=19558
http://forum.eeeuser.com/viewtopic.php?id=11158
N.B.: Version 0.2 of this utility has been released, with some important differences compared to 0.1. This utility is still developing rapidly and there are not yet established procedures that this wiki can describe. Among the important changes, it is possible to manually control the eee-pc's fan speed (which makes this utility even more dangerous). For now, you will have to make your way through the mail lists, so see what configuration works best for you.
The mail list thread for this topic - VERSION 0.1 - is here:
http://forum.eeeuser.com/viewtopic.php?id=3759&p=1
The mail list thread for this topic - VERSION 0.2 - is here:
http://forum.eeeuser.com/viewtopic.php?id=9797&p=1
Note that this overclocking increases both the CPU and memory speeds. However, even overclocked the memory speeds are well below what most DDR2 memory is capable of, so the memory is not likely to be stressed by overclocking in this way.
As an aside, there is now a similar utility for Windows XP. See: Eeectl: http://forum.eeeuser.com/viewtopic.php?id=8808
The source code for the kernel module can be found from: http://code.google.com/p/eeepc-linux/
To compile the module yourself, you will likely have to install the kernel headers.
Download the tar ball and unpack it. See the README; cd to “module” and execute “make” which should compile the “eee.ko” kernel module.
Before the version 0.2 eee.ko module can be installed, the i2c_i801.ko module must be installed, since eee.ko uses that interface to the hardware. You can insert the module manually by using “insmod eee”, or you use the prescription below to have the modules load automatically at startup. To check that the module is installed, run “lsmod | grep eee” from a terminal window.
Inserting the module will create the directory /proc/eee , and “cat /proc/eee/fsb” should report back “70 24 0”, meaning the FSB is at 70 MHz and the low-voltage setting (0) is being used. Listing the /proc/eee directory will show other options and information, such as portals to reporting and controlling fan speed and reporting the temperature of the CPU.
If you don't know how to, or don't want to, compile the module by yourself, get the working binary module from this site: http://kibobo.free.fr/EEE/acpi/eee.ko This kernel module will likely only work with the “2.6.21.4-eeepc” kernel version.
Here is a precompiled version of the 0.2 kernel module for eeeXubuntu kernel 2.6.22-14-generic. To make it work under eeeXubuntu have a look at [http://forum.eeeuser.com/viewtopic.php?pid=95046#p95046|this post]. http://www.informatik.uni-oldenburg.de/~graves/eee/eee.ko
The FSB is controlled by adjusting the frequency in /proc/eee/fsb. The frequency can be set to any integer value. Nominally, values should be between 70 MHz (630 MHz CPU) and 100 MHz (900 MHz CPU). In general, jumping straight from 70 Mhz to 100 MHz will cause the system to crash, so increasing to intermediate frequencies is advised.
Here is a simple script to overclock the FSB:
sudo sh -c 'echo 85 24 1 > /proc/eee/fsb' sudo sh -c 'echo 100 24 1 > /proc/eee/fsb' echo "FSB overclocked to 100MHz"
By using sudo, the script will run even if you are not in a root account. Remember to make it executable: if you saved the script as overclock.sh, execute “chmod 755 overclock.sh”.
The first parameter is the N multiplier, and the second parmeter is the M divisor. The third parameter is a flag for the embedded controller (nominally, 0=70Mhz and 1=100Mhz). The third parameter is a voltage setting: “0” is undervolted, “1” is normal (or over?) voltage. If you are having problems going above a certain FSB speed with the third number as “0”, set it to “1” and it might work a little more reliably.
You can check that the FSB speed was changed by “cat /proc/eee/fsb”. Then try running some of your favorite benchmarks to see if the results are better by 30-50%.
N.B.: It is common practice to check the speed of a CPU by “cat /proc/cpuinfo”. In this case, that procedure will not work; /proc/cpuinfo will always report 630 MHz, even though the system may in reality be at 900 MHz. The only way to verify 900 MHz (or any speed different than 630 MHz) is to do some benchmarking.
Here is a small, but fairly complete, shell script for changing the FSB speed, for version 0.1 of the module! It will load the eee.ko module if it is not currently loaded. Put the script in, e.g., /usr/local/bin. Change its permissions to allow execution.
To run the script, execute: “fsb -i #1 {high|low|med|#2}”, which will set the increments for the frequency changes to #1 and change the FSB speed to high (100 MHz), low (70 MHz), medium (85 MHz) or user-defined #2 MHz. So, “fsb -i 3 90” will install the eee.ko module if needed, and change the FSB speed to 90 MHz at 3 MHz increments.
With no argument the script will display the current speed. With a bogus argument it will display a usage message. You can adjust min/max/step with defines at the top of the script. The script uses a third parameter value of “0” for all frequencies.
fsb.txt.gz (sorry about the gzipped file - a requirement of this wiki apparently)
To get the module to autoload at start up, first you will need to be root: “sudo bash”.
Move the module to the /lib/modules/[your kernel]/kernel/drivers/acpi directory: “mv eee.ko /lib/modules/[your kernel]/kernel/drivers/acpi” For the Xandros kernel, [your kernel] will be “2.6.21.4-eeepc”. You can move it to any directory in the /lib/modules/[your kernel]/ folder, but it seems appropriate to put it in the acpi folder.
Next, register the new module by executing: “depmod -a”.
Finally, add “eee” to the bottom of the list of the /etc/modules file, using nano, vi or your favorite editor. For version 0.2, also add the “i2c_i801” module there as well, above “eee”.
Now the module should load on your next reboot.
Setting the system to overclock during boot up is not recommended, however. If the system gets set up such that it experiences an overclocking crash during boot up, you'll then have to boot to a rescue system to fix the problem.
It seems to be fairly common on some systems to experience a system crash while changing FSB frequencies. The crashes can occur erratically; changing FSB frequencies may work several times, and then a system crash will occur. The solution to the problem seems to be to make the FSB frequency change more gradual by using more intermediate frequencies. Reports are that frequency changes at 1-Hz increments seem to be trouble free. Also for FSB frequencies above about 85 Hz, the third parameter should probably be set to “1”. Again, “your mileage may vary”. The FSB frequency change procedure is a little tempermental.
After a crash, the system can usually be reset by holding the power button down for a few seconds. This causes the power to be turned off to the eee-pc. Sometimes, however, the system can get so stuck that it can be restored only by unplugging external power or unplugging the battery for 10 s or so to completely unpower the device.
With the eee.ko module loaded, the /proc/eee directory will have three files relating to fan speed:
fan_manual: Set to 0 or 1. 0 means the fan speed is set automatically by the BIOS, depending on the CPU temperature. 1 means the fan speed is entirely user controlled, and if it is set improperly you'll burn out your cpu!!!
fan_rpm: Reports back the RPM of the fan.
fan_speed: A value between 0 and 100. The value is in percent, and gives the percent fan speed. 0 is off (you'll smell your cpu cooking), 100 is maximum fan speed (which will drown out the 747's flying overhead).
The purpose of the manual fan control is to turn down the fan speed a little to make a quieter eee-pc. Only after fan_manual is set to 1 (“echo 1 > /proc/eee/fan_manual” should be obvious by now) will changes to fan_rpm and fan_speed have any effect. WARNING: If you set the fan speed improperly you may well burn out your CPU. Please use caution; this is a dangerous option!!!
lmsensors is a linux utility for reporting on the states of the various components of a system: fan speeds, voltages and temperatures. To use this utility, start by installing the lm-sensors deb package. Once configured, the system state is reported by executing the “sensors” command.
However, lmsensors doesn't work on the EEE, because the sensor chips are on a private bus accessible only to the embedded controller (EC). The EC exports temperature information through ACPI:
alan@alan-eeepc:~$ cat /proc/acpi/thermal_zone/TZ00/temperature temperature: 52 C
It develops that not every eee-pc can run stably at 100 MHz FSB. A typical system failure in overclocked mode is a screen that is blotto, with keyboard and touchpad unresponsive; generally a hard reset is required (hold the power button down for 5 seconds to force a system powerdown). This is generally a bad thing to happen to a system, and can lead to loss of data, disk failure, etc. One theory is that not all memory chips are capable of running stably at higher FSB speeds.
Note that there are two kinds of system crashes here: one that can occur during a change in FSB frequency, and one that occurs some time after the FSB speed has been changed. The former does not indicate instability, merely a hiccup in the system when the FSB changes. The latter indicates that the system is overclocked beyond its capabilities. This section is concerned with the latter.
Experience indicates that using the p4-clockmod kernel module is to be avoided. This module seems to be one cause of system instability.
So, when using the eee.ko module, it is prudent to test out your system at a variety of speeds to determine the speed at which your system will run stably. This involves setting your FSB at increasing speeds, and running stress tests on your system at each step to ensure stability. So start at 85 MHz, say, and run the tests; if those tests pass, up the speed to 90 MHz, say, and run the tests, etc. … 95 MHz, 100 MHz. If a system error is experienced and the third parameter is set to “0”, then setting the parameter to “1” will sometimes increase system stability. These tests determine the maximum FSB frequency for which a system will run stably.
One test you can try is to leave “glxgears” running for a time - 10's of minutes? Systems have been known to appear stable at 100 MHz, but then freeze when glxgears is left running.
Another commonly used test is “prime95” binary available from: http://www.mersenne.org/freesoft.htm Prime95 is in practice used to calculate prime numbers, but it has been adopted by system overclockers as a tool for stress testing a system. The software runs heavy numerical calculations that stress cpu, cache and memory. To run the stress test, run “mprime -t”. It is generally recommended to run the test for some hours, although if the system is suffering any flakiness, the test will likely fail within a few minutes.
You can also install a “stress” package that can be used for this very purpose.
The standard memory test “memtest86” won't work in this case, because that test is run on its own right at boot up. To overclock the FSB, the linux system has to be started with the eee.ko module installed, of course!
The indications are that driving your eee-pc at 100 MHz with “normal” voltage will use only slightly more energy (5-10%) and not lead to excessive overheating. Increasing the voltage by setting the third parameter to 1 increases power consumption by about 14%. Using a higher voltage leads to a warmer laptop.
During times of heavy CPU usage, the temperature of the CPU will rise. You can monitor the temperature of the cpu (?) during the stress tests above by executing “cat /proc/acpi/thermal_zone/TZ00/temperature” - temperatures should generally be between 50 and 60 C. Reports suggest that at 68 C the cpu fan of the eee will go to full speed, which stops additional warming fairly well. Temperatures in the mid-60's or above are on the warm side, however.
The precise temperature limits for the eee-pc are unclear, but the temperature limit for the CPU appears to be 90 C.
Here are the results of one test, which measured the current draw of the system at the indicated FSB speeds (N):
N M mA power 90 24 1271 - 103,9% 85 24 1248 - 102,0% 70 24 1223 - 100,0% 65 24 1216 - 99,4% 60 24 1210 - 98,9% 55 24 1199 - 98,0%
which shows that the current draw at 90 MHz is only a few percent more than at 70 MHz.
You may be tempted to underclock or use the p4-clockmod kernel module to slow the CPU speed down. Underclocking or slowing the CPU speed down with p4-clockmod will not generally save much power, but may cause system instability. There does not seem to be much point to doing this; but please post to the mail list if you find otherwise!
There are apparently some issues with degradation of the video (LCD or VGA out) when the FSB is clocked at 100 MHz. This problem may be a non-issue, however; not much has been reported on the mail list about it.
It's necessary to restore the default FSB frequency before hibernation or suspend. You should add a script to automatically downclock FSB before suspend and overclock after resume. The script will depend on your distribution, as well as how you set up the custom FSB frequency.
Starting with Ubuntu 8.04 (Hardy Heron) uses pm-utils for hibernation and suspend, and so do recent versions of SuSE linux. For pm-utils, you need a single script in /etc/pm/sleep.d/ which should handle both suspend and resume. Older Ubuntu distributions use acpi-support instead, which requires two separate scripts under /etc/acpi/suspend.d/ and /etc/acpi/resume.d/.
Here's an example script for pm-utils. It assumes you have an init script called eee-overclock.sh to control FSB frequency. If you don't have eee-overclock.sh, you can simply edit this script to meet your needs (i.e. replace /etc/init.d/eee-overclock.sh start/stop with commands you need). It should be saved as /etc/pm/sleep.d/00downclock.
#!/bin/bash
case "$1" in
hibernate|suspend)
if [ -e /proc/eee/fsb ]
then
fsb_freq=$(cat /proc/eee/fsb)
fsb_freq=${fsb%% *}
if [ "$fsb_freq" != "70" ]
then
touch /tmp/eee-overclock-restore
/etc/init.d/eee-overclock.sh stop
fi
fi
;;
thaw|resume)
if [ -e /tmp/eee-overclock-restore ]
then
rm /tmp/eee-overclock-restore
/etc/init.d/eee-overclock.sh start
fi
;;
*)
;;
esac
And don't forget to make it executable:
chmod +x /etc/pm/sleep.d/00downclock