I ran into this problem and found the solution with a little research. It is a bug in the kernel, and the bug is fixed in the next kernel release--but Ubuntu people who have experienced the problem will have to wait till October. In the meantime, do this:
1. The kernel can use one of several timers. to check which yours is using: Open a terminal and become root (sudo -s). Type
Code:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
The result identifies the clocksource that has gone wrong.
2. Now find out what other clocksources are available:
Code:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
You'll see a list of words (e.g. acpi_pm hpet jiffies).
3. Test an alternative clocksource, e.g.
Code:
echo "hpet"> /sys/devices/system/clocksource/clocksource0/current_clocksource
You should notice an immediate speedup in the system clock. If so, go on:
4. We'll add a kernel parameter to make the kernel use a workable clocksource.
nano menu.lst
Scroll down to the first menu item (a group of lines beginning "title root kernel" etc.). At the end of the "kernel" line (which shows the command line that starts the kernel), add a "clocksource" parameter specifying the clocksource that worked for you in step 3 above. For example, change
Code:
kernel /vmlinuz-2.6.20-16-lowlatency root=UUID=030313ac-ece9-49bd-8c39-
5ff6323c34a7 ro single
to
Code:
kernel /vmlinuz-2.6.20-16-lowlatency root=UUID=030313ac-ece9-49bd-8c39-
5ff6323c34a7 ro single clocksource=hpet
5. Save the file and
Everything should work correctly now!