Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Ok, now I have real server fault ;)

After some time from booting (about one minute) my server hangs. All I can do is hard reset. Then after restart in /var/log/kern.log I can find:

Jul 29 22:38:57 leonidas kernel: [   90.729598] longhaul: Failed to set requested frequency!
Jul 29 22:38:57 leonidas kernel: [   90.731252] longhaul: Enabling "Ignore Revision ID" option.
Jul 29 22:38:57 leonidas kernel: [   91.201461] longhaul: Failed to set requested  frequency!
Jul 29 22:38:57 leonidas kernel: [   91.201482] longhaul: Disabling ACPI C3 support.
Jul 29 22:38:57 leonidas kernel: [   91.204230] longhaul: Disabling "Ignore Revision ID" option.
Jul 29 22:38:58 leonidas kernel: [   91.416133] longhaul: Failed to set requested frequency!
Jul 29 22:38:58 leonidas kernel: [   91.416152] longhaul: Enabling "Ignore Revision ID" option.
Jul 29 22:38:58 leonidas kernel: [   91.960048] Clocksource tsc unstable (delta = -105611479 ns)

I found some resources on the net, and it said to change clocksource, or disable ACPI. I tried disabling ACPI but it didn't help (but I noticed there was longer time before hanging). I can't change clock to hpet, because my system doesn't have such one.

Output of cat /sys/devices/system/clocksource/clocksource0/available_clocksource:
acpi_pm jiffies tsc

My system is ubuntu server on VIA Epia hardware.

share|improve this question
up vote 2 down vote accepted

Your CPU is refusing to co-operate with the system as it attempts to control the CPU's clock rate. This appears to be a known issue with certain hardware; the longhaul driver is broken for some configurations, which in turn causes issues with CPU power saving, a.k.a. CPU frequency scaling. If you go back and look at your original error posting, you can clearly see that the longhaul driver is "alive and well" even though it is supposedly "broken". Getting this disabled or overridden with a different clocksource will be your goal.

TSC stands for 'time stamp counter', which is supposed to increment consistently with the speed of the CPU. When the CPU dynamically changes frequency, the TSC 'changes' or 'deviates' and the kernel notices it; hence, the message in the log from the kernel about the TSC. The trick here would be to locate the CPU frequency governor and turn the feature off, or enable maximum CPU all the time. Basically, you want the CPU to run full-throttle with no frequency scaling. On Ubuntu, this can be influenced by the type of CPU as well - my personal PC is an older Athlon XP box, so it installs the powernowd daemon to control the CPU frequency because it's an AMD CPU, even though it can't use this feature. Intel CPUs will (probably) use something else, and VIA still something different. You may wish to do

apropos power

...and see what programs are suggested in the man pages (which in turn, will give you some quick clues as to what programs might be the culprit).

Another approach is to explicitly set the clocksource to acpi_pm, which appears to be supported based on the output you've provided. You can also try jiffies but acpi_pm will probably give you better results.

Some searching has hinted that you're probably using a VIA-based chip, which has had occasional driver issues when dealing with CPU frequency scaling. As I don't know your specific hardware setup, I really can't tell you more than this. Good luck.

share|improve this answer
Yes, my system is VIA Epia – amorfis Jul 30 '09 at 12:24

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.