2

We are running RHEL 6 boxes on HyperV with Windows Server 2012. On a few on our RHEL boxes, I am seeing this error in /var/log/messages 

kernel: Clocksource tsc unstable (delta = -62519781 ns).  Enable clocksource failover by adding clocksource_failover kernel parameter.

The current clock source is - 

[root@server ~]# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hyperv_clocksource

And the available clock sources are - 

[root@server ~]# cat /sys/devices/system/clocksource/clocksource0/available_clocksource 
hyperv_clocksource tsc acpi_pm jiffies

My question is - 1. Why is the server complaining about tsc when the clock source is HyperV? 2. Which clock source should I select as failover?

P.S - I am aware of the Red Hat solution - https://access.redhat.com/site/solutions/434883. I am just wondering why this is happening?

For those without RedHat Access, the solution is as follows -

Change the clock source to another available clock on the system First, find the available system clock sources:

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource

**** An example of the results is below:*

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource 
tsc hpet acpi_pm

Next, check the current clock source in use:

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource

**** An example of the results is below:*

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource 
tsc

Finally, set the new clock source:

echo <new clock source selection> > /sys/devices/system/clocksource/clocksource0/current_clocksource

To make this change persistent across system reboots, the following must be added to the kernel command line in /boot/grub/grub.conf:

clocksource=<clock source choice>
Sidd
  • 103
  • 1
  • 9
  • if you use clocksource_failover as recommended, when linux doesn't work well with a clocksource, the system uses other clocksource – c4f4t0r Jan 07 '14 at 07:58
  • Right, I understand that. I am just wondering why Linux says tsc is unstable when hyperV is selected as the clock source. – Sidd Jan 07 '14 at 15:09

1 Answers1

1

The complaint is just that it is having to fallover from it's default of TSC, and you don't have the module for it to detect the best one. Apparently it is selecting the correct one already so this isn't an issue.

The warning is just there so you know what to do if the kernel is choosing the wrong alternative clock source by default.

As of why the TSC timer is not producing a reliable timer, this could be a bug in the virtual machine software. You may want to check your virtual machine manual. There is also an errata in some processors with the C-State 2 and lower CPU idle states disrupting the TSC timer. Either way I don't think it's a major concern.

Robert Wm Ruedisueli
  • 216
  • 1
  • 3