Kernel clock issue "Clocksource tsc unstable"

Hal Burgiss hal at burgiss.net
Fri Feb 27 18:11:15 UTC 2009


On Fri, Feb 27, 2009 at 11:50:11AM -0500, Rashkae wrote:
> > I have probably at least 6 systems on 8.04LTS, but only have this
> > issue only on two of them, and these are radically different hardware.
> > At first I suspected a hardware issue when I only had this issue with
> > one machine. Now I have it with 2 so I can't imagine its hardware. To
> > make it worse, its very sporadic. On the one system, it happens
> > approximately once a month. The other system is new, has been running
> > about 2 months, and this was the first occurence.
> > 
> > One message I did grab says:
> > 
> >  06:05:11 dio kernel: [1617517.563814] Clocksource tsc unstable (delta = 4686705598 ns)
> >  06:05:11 dio kernel: [1617517.573798] Time: acpi_pm clocksource has been installed.
> > 
> > That was during a time server sync. In exactly 6 hours (at 12:05) that
> > same day, the clock stopped updating, logging stopped, ssh was fubar,
> > and I had to physically go to the datacenter and hit the reset button
> > to fix it. 

[...]

> Sorry I can't really give you a canonical answer.  tsc is an infamously
> poor time keeper, but the kernel devs seem to prefer it over hpet
> (Intel's High Precision Event Timer) because of performance.  (tsc is
> right in the cpu, wheras hpet needs to access a chip on the mobo).
> 
> On my hard system where hpet is available, hardy defaults to that.
> However, some systems do not have hpet, and kernel defaults to tsc.  In
> your case, tsc is deemed unstable and switches to acpi.  Why this would
> cause your clock to stop updating however, is a mystery, unless the acpi
> hardware on your system is broken.

Hardware was my first strong suspicions. But when it happened on a
second system, then I don't know. This would be on 2 very radically
different systems (ie hardware). 
 
> The first step to resoling this, however, will be to determine what
> clocksources you have available, and then choose one on boot (as a
> kernel boot parameter.)
> 
> sudo cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> 
> and:
> 
>  sudo cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> 

On the older system I get:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
 tsc acpi_pm jiffies 

and its using tsc ATM. On the other, newer system:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
  acpi_pm jiffies tsc 

and its *now* using acpi_pm, but I don't know what it was before
resetting it today. Its possible, that there had been a kernel update
somewhere and it did not kick in until the reboot and the clocksource
might be different. I had no log data at all on that system since
yesterday at 6:05, so I am in the dark on that one.


> You can specify one of the available clocksources by editing your grub
> menu.lst file and appending a clocksource= option to the kernel you
> boot.  For example, you can try clocksource=acpi_pm and test if acpi
> works if you boot with it rather than switch to it.  If acpi_pm doesn't
> work reliably on your systems, I would then try hpet or pit if those are
> available.

Thanks for the info! Very helpful.

-- 
Hal





More information about the ubuntu-users mailing list