Clocksource tsc unstable (delta = -127665427 ns)
kernel 2.6.21.3
Hi,
The tsc clock source keeps getting marked unstable and falls back to using acpi_pm on kernel 2.6.21.3. This is directly linked to using cpu frequencing scaling. If I leave default governer as performace is fine, second I set to ondemand or anything the changes the current frequency the unstable msg appears.
What I what to know is:
Is this normal and expected ? If so ignoring the msg is fine.
Will this cause a problem at the point a different clock source is used ?
Can I set the system to always use acpi_pm rather than the tsc
(I always use cpu frequency to save power as cpu use is low) ?
I have had a good google around but can't find clear answers. So please someone put my mind at rest. I did not have this problem in 2.6.14 so I am assuming the only clock source used there was acpi_pm and tsc as a clock source is new a edition to the kernel.
regards
Crispy
I currently am having this
I currently am having this same error message during boot in which startup lags for a good 2 minutes and it then continues to boot. I am using kernel-2.6.21.4.
Thx for no one getting back
Thx for no one getting back to firstly. I find it staggering that having posted across 3 different forums that not one reply shedding any new information.
Chappy who is having the same problem. Most likely you have cpu frequency scaling on and there might be a problem at point the govener switches over.
Check you have installed another clock source like acpi_pm
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
If so you can try turning off cpu frequency scaling in the kernel (or set to performance) which 'should' elimanate the unstable msg and speed up boot. Temperature/power is not an issue who cares anyways.
OR/AND
You can try adding the below to your kernel command line (stick it on the same line as your kernel in /boot/grub/menu.lst). This won't get rid of the unstable line but it will force the kernel to use a more stable clocksource so there should be no trouble switching over anymore (if indeed there is trouble to begin with).
clocksource=acpi_pm
Please the post the results.
No, "Clocksource tsc unstable" kernel msg is not a problem
See this thread http://ussg.iu.edu/hypermail/linux/kernel/0707.1/0621.html
As far as i know Pentium M processors have dynamically changed clock
speed (ofc to save power). That's why kernel notice that TSC is
unstable (it is indeed). On my Athlon 64 I have similar situation,
because CPU frequency is dynamically changed.
I don't think that there is an easy way to fix it (it is not even a
bug), time-stamp counter is not perfect...
Cheers, Leon
the kernel parameter
hmmz,
clocksource=acpi_pm
doesnt work, cant we disable tsc and only enable acpi ...
this message isnt critical, but on every boot with 2.6.22 it will stands for 10 secs.
i think i'll use 2.6.18 within i ve got no further problems
number5
I have Ubuntu 8.04, kernel
I have Ubuntu 8.04, kernel 2.6.24-17-generic on laptop asus u5f and option clocksource=acpi_pm solve this problem. Thanks!
I had the same problem.
I had the same problem. Mplayer, and xine video didn't work (except when using the RTC timesource). I added "notsc" on the kernel commandline and everything has worked beautifully for me after that.
AMD Turion Acer Aspire 5100 laptop
Same issue when booting to TRK (see trinity home .org) linux live cd build 299 beta 3.3.
Same laptop would boot the build 279 without problem which used an older kernel version.
Adding notsc to the end of the kernel (or is it boot?) parameters helped although I am not yet sure if the wait now occuring in the booting process has anything to do with the timesource or is yet another issue. This is a beta build.
CMOS setup had no option for forcing the CPU to stay at one performance level.
it simply means either your
it simply means either your processors clock is being modulated from either the motherboard or the kernel itself. It's fine but you guys should be using hpet or rtc instead of apic_pm preferably hpet as its better than rtc
adding clocksource=hpet
adding clocksource=hpet solved the problem for me (ubuntu 8.04) -> faster startup
one may need to change clock source...
One may need to change clock source when using full virtualization with i.e. VMware Server.
I had to change the clock source for Debian Etch with 2.6.8 kernel (to clock=pit), because it was loosing about an hour every day.
I thought with vmware you
I thought with vmware you can define the max mhz speed in the config file to avoid that. It certainly bugs me with hints if I don't