Linux Kernel complaining about TSC when selected clock source is Hyper V

8,866

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.

Share:
8,866

Related videos on Youtube

Sidd
Author by

Sidd

Updated on September 18, 2022

Comments

  • Sidd
    Sidd almost 2 years

    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>
    
    • c4f4t0r
      c4f4t0r over 10 years
      if you use clocksource_failover as recommended, when linux doesn't work well with a clocksource, the system uses other clocksource
    • Sidd
      Sidd over 10 years
      Right, I understand that. I am just wondering why Linux says tsc is unstable when hyperV is selected as the clock source.